Threads(PThreads) stopping execution and going into wait state?

Sounds like you might be suffering from a deadlock. Do your threads ever hold more than one mutex at a time? (e.g. Pthread_mutex_lock(&mutex1); pthread_mutex_lock(&mutex2);) If so, do they always lock their simultaneously-held mutexes in the same order?

If they don't, that would be a problem.

Sounds like you might be suffering from a deadlock. Do your threads ever hold more than one mutex at a time? (e.g. Pthread_mutex_lock(&mutex1); pthread_mutex_lock(&mutex2);) If so, do they always lock their simultaneously-held mutexes in the same order?

If they don't, that would be a problem. If thread T1 does the aforementioned locking sequence, but thread T2 locks mutex2 and then mutex1 (while still holding mutex2) then that is all that is needed to cause an occasional deadlock... which would mean that T1 is holding mutex1 and waiting for mutex2 to become available, while simultaneously T2 is holding mutex2 and waiting for mutex2, and both are stuck forever. Or if you're really unlucky, the deadlock could involve a cycle of 3 or more mutexes.

Note that even if your own code isn't locking a second mutex explicitly, it's possible that some library or function call that your code calls out to is locking its own mutex internally. That, combined with your own held mutex, could be sufficient for a deadlock also. Your best bet would be to run your program under a debugger (for example gdb), and then when it locks up, break into the debugger and print out the current stack trace of each thread (via the "where" command) to see where it is blocked at.

My application has only one mutex and it is just to lock the array read/write, maybe it is not because of the mutex! I will try gdb though I do not exactly know when the problem will occur, sometimes half hour into the run, sometimes 2 hours into the run. – cricketfan99 Jan 16 at 4:05 Also I have a core dump that I took (kill -6) when the program was stuck.

How can I read the stack traces? I am new to reading core dumps. I opened the dump but could not make much sense out of it.

Thanks in advance. – cricketfan99 Jan 16 at 4:13 Have you tried gdb myprogram core. Xxx?

Then you can inspect the program's memory when it died, seeing different threads status (backtrace) and variables. – Antoine Pelisse Jan 16 at 9:40.

For sure, there is no bug in the provided example. The real bug in your code is somewhere else - this is typical in multithreaded applications, you shouldn't focus just to this particular array. Look for the bug elsewhere.

Even when you think there is nothing more related to threads where multithreaded deadlock can occur, there is something for sure!

There was problem with the way I was using one of the calls to an external library that caused me to go into self-deadlock mode. Thanks to everyone who tried to help me.

I was going to say, check your mutex locking and unlocking, especially when using conditions, but you found your problem. By the way....you don't necessarily need to use a mutex to read or write values to a shared array. Check out gcc atomic operations if you need more speed!

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.