I wanted to get my concepts a bit clearer regarding the malloc() call in C. I have a multi-threaded application in which the main thread spawns an arbitrary number of worker threads (pthreads). Each worker thread then runs an infinite function (the function included is from another .c file and implements a while (1)) where by it is responsible for continuous network I/O.
For each thread I needed a hash table so I used hash map provided by the glib. What I did was is that I initialized a hash map inside each thread's function which on the back end allocates some initial memory for the structure and it can then grow as the need arises.
Now when I ran the application it threw errors including segmentation faults and inability to allocate any memory for the structures. It took me a while to find out that the errors were due to the inability to allocate memory for the hash maps. What I thought was (still think) that each thread will have its own memory space and it will allocate a block of memory for its respective hash map inside its own memory block. I was able to fix the error by using mutex locks before and after the initialization of the hash maps like (sudo code):
lock mutex
initialize hashmap
unlock mutex
The code for initializing a hash map that is called in each thread is :
GHashTable *g_hash_table;
g_hash_table = g_hash_table_new (g_int_hash, g_int_equal);
Although it solved the problem but I got a little confused after this. Why does this problem occur without he use of locking as each thread has its own memory space for the function it implements and it shouldn't be conflicting with other threads while allocating memory of its own. All guidance much appreciated.
thanks.
Each thread will not have its own memory space - all threads can access the memory of all threads within a process.
That said, each thread is allocated its own stack within this space, so auto-vars are OK if not misused, and malloc/free SHOULD be thread-safe, so a dynamically-allocated hash map, (pointed to by an auto-pointer on the thread stack), should be fine.
If there is a choice, make sure that you are linking against thread-safe versions of the libraries.
The mutex lock should not be necessary. If it's solving the problem, then you're right - something, malloc/free maybe, is not thread-safe when it should be.
You sure that the hashmap code only references auto or malloced storage? No globals/statics have crept in?