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.
Yes. For example say you call a bunch of functions or sub-routines in a c-program, they would appear on the call stack in the following order (where function2() is the most recent function to be called, function1() was called before function2() etc... )
function2()
function1()
main()
Please let me know if that helps in anyway
You are absolutely correct.
A main is also a thread; they way it has a calling sequence to a function, the way a posix thread calls to functions look like.
Ramen: Can't we call epoll()/kqueue() in the threads; why to call in the main thread (in the hi-performing server apps -as you have said) even in the asynchronous nonblocking calls?? I know kqueue() a bit but still not much can we discuss this in the rest of the thread?
thanks Praveen
Praveen: As you yourself noted the utilization of whatever event servicing mechanism you use is going to execute in a thread. Soo I don't think that your question is ingenuous.
My point was that if you service a client with a separate thread you will run out of resources pretty quickly given a sufficiently complex interaction and number of clients.
With asynchronous service and a single thread you do not incur the memory overhead of separate threads and stack space for each.
Frankly Ramen, I never got a chance to use epoll()/kqueue(). I've only been able to use select()/poll() for such event notification machanism, at least in the commercial projects, we've worked on. I also wanted the discussion to be carried further on event notification machanisms so that we get benefited along with many others in the forum and kqueue()/epoll() are good candidates to be discussed. Pl don't take otherwise.
Still may we discuss them further on which Unix/Unix Like platforms support it apart from Linux/BSD (which I've only worked so far)?
Praveen:
Your use of select and poll in commercial (I'm reading as designedly portable software to various unixes) is understandable. epoll and kqueue are, after all, linux/*bsd specific.
Still pselect/select and poll are perfectly good event interfaces after all.
epoll seems to have a superior interface to select/poll with the notable absence of signal processing ala pselect.
I haven't worked with kqueue but am familiar with the interface from reading 'The Design and Implementation of The FreeBSD Operating System'.
.