Thread: Basic Multithreading and Proper management of char* arrays.

  1. #1
    Registered User
    Join Date
    Apr 2004
    Location
    Ohio
    Posts
    147

    Basic Multithreading and Proper management of char* arrays.

    This is a two part post so bear with me.

    Question Part 1, char* memory management

    I generally work with C++ and so avoid C strings as a rule but I'm working with a library developed in C which requires POD's to function properly so I'm forced to work with char* arrays (all of the access functions are wrapped inside C++ class interface functions so I can at least keep it all in one neat and tidy package).

    I'm not doing anything advanced with said string (e.g., no strcmp()'s, strcat()'s, strlen()'s, etc.) so I'm really only worried about properly initializing, freeing, resizing, etc. With the below code (assuming that the actions filling the array with data knows the correct size inclusive of a trailing null terminator byte), is it correct in terms of properly managing the memory allocated?

    Code:
    char *myString = new char[someSize];
    
    /* Perform some sort of action that fills the array with meaningful data. */
    
    free(myString);
    
    myString = new char[someOtherSize];
    /* Repeat process. */
    Question Part 2, Threading

    Hope this is the appropriate forum so if it's not point me in the right direction and I'll edit this post and move this part of the question to a more appropriate thread.

    I'm very very new to multithreading. I generally understand how threading works on low level but I don't know how to effectively apply it within my own application. I'm using SDL's functions for creating and managing threads and mutex's to keep things simple and cross-platform.

    Various states are set before the thread starts and are dependant on when the thread completes. While the thread is executing, it will be accessing two variables, the above c-string which will only be accessed within the function executing in a separate thread and a float value that's accessed by both threaded function the parent thread simultaneously.

    Creating a thread is straight-forward. Passing in the data that I need to access is also straight-forward. My question is primarily about when and where I should use a mutex to properly lock a particular resource, if at all, and which resources need to be locked.

    Thanks for your time!
    Last edited by leeor_net; 08-14-2009 at 12:05 AM.

  2. #2
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    1) Bad, bad, bad! Never use new and free with free. Use new and free with delete or use malloc and free with free. Anything else will result in undefined behavior.
    2) Use a mutex to lock before writing to a variable that is used by two or more threads. And unlock afterwards, of course. It might also be a good idea to lock before reading the shared variable, too.
    Last edited by Elysia; 08-14-2009 at 04:40 AM.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  3. #3
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,981
    In addition:
    1)
    Use a vector<char> to manage the string buffer. For const char* strings, you could still use std::string::c_str. You could use the stack if dynamic memory isn't truly necessary.

    2)
    >> the above c-string which will only be accessed within the function executing in a separate thread
    Since it's not being accessed by multiple threads at the same time, no synchronization needed. The only time you don't need synchronization with multiple thread accesses, is if all accesses are read-only.

    >> and a float value that's accessed by both ... [threads] ... simultaneously.
    If one of the threads performs a write, then access needs to be synchronized.

    gg

Popular pages Recent additions subscribe to a feed