Threads(PThreads) stopping execution and going into wait state

I have been having this problem wherein my threads stop execution and go into a wait state(reason : unknown). Pseudo code is posted below followed by some explanation

int arr[1000];
T1
{
tmp = arr[i];
}
T2
{
tmp=arr[i];
}
T3
{
arr[i] = value;
}
Main()
{
spawns of threads and waits for them to finish;
}

So the only 开发者_运维问答thing that is shared across these threads is the array, T3 writes into this array and T1,T2 read from it and use it for some purpose. When I execute the program all three threads work fine and do what is required of them but when I try to run it for longer periods, after a while they stop execution and go into a wait state. The threads are still in the process mix but in less idle state. I do not know why this is happening and would greatly appreciate if someone can provide any useful pointers as to how I can find a resolution to this problem.

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!

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.

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!