Programming

Is it generally not a good idea in a multithreaded program to make lots of malloc calls (dynamic memory requests) because of the limited nature of the memory heap ?

Out of curiosity (warning it may sound silly), but would using mutexs (mutual exclusion) help to minimise chances of runtime errors ?

regards

Its not about a good or a bad idea in using malloc() its about the requirements of the project. You cannot have a project using only static variables. In large projects, without malloc()/calloc(), its not possible to create dynamic variables and objects.

Yeah, the following problems are more prominent in multithread environments than in the single threaded environments ---:

1) Getting dangling pointers
2) Freeing a pointer multiple times (freeing in only one function; but getting the same function called in context of many threads)
3) Getting memory leaks easily.


It's always a trade off; speed vs size + flexibility --:
Accessing static variables are faster (created on the program stacks) than accessing dynamic variables (as these are created on the heaps) and you loose flexibilities (required for large server apps) and the binary size thus produced is bigger compared to using the dynamic variables (unsuitable for embedded applications).

However there are some good tools available like ValGrind, Dmalloc etc. that help in debugging memory related issues and they are very helpful if used along with GDB.


As of the second part of your question on mutexes; it's a bit vague as mutexes are used to control simultaneous access to shared resources where there is a race conditions.
If its not a condition of simultaneous access; one should ALWAYS check as follows --:

If (NULL != myPointer){
..... .....
//use the pointer
.... ....
}; //Before using any pointer to operate through it.

OR in mutual exclusion conditions----:

mutex_lock(&myMutex);
//Below pointer operates on shared memory area.
if (NULL != myPointer){
..... .....
//use the pointer
.... ....
}; //Before using any pointer to operate through it.
mutex_unlock(&myMutex);

Dynamically allocated memory (heap) in a threaded environment, as noted ,is neither a good or bad idea.

What can be a bad idea is relying on static (stack) allocations anywhere.

Sorry, what I actually meant to say is whether using mutexes would be a good idea to help control access to the heap for simultaneous malloc() requests made by different threads.

However you did somewhat answer my question in your post, so thanks for that

Ramen Noodle, could you expand on your statement where you mention that using stack allocations anywhere is a bad idea ? btw is this related to the LIFO (last in, first out) nature of the memory stack in general ?

cheers

No. This has more to do with the implementation restrictions of a threads stack
If it's pthreads and you aren't already familiar with the stack specific functions maybe
you could take a look there. man -k pthread | grep stack

Also have you considered using thread specific data instead of barrier type mutex reservations?

Out of curiosity, does the thread stack work in a similar way to the function call stack (LIF0) ?

Also would you know any good places I can visit to learn more about thread stacks ?

cheers

By definition a stack is LIFO, right?
I don't know of any good sources for thread specific stack details. I do know that per thread stack size issues are fairly common, whether it be on a per process basis or on usage of the thread's stack internally.

This is one of the reason why high performance servers don't use individual threads for client handling, choosing instead high performance non-blocking event mechanisms like epoll and kqueue.