pthread_cond_signal operation

[amit_ambitions]

hi,

it is said and wellknown that before sending signal by pthread_cond_signal() we have to lock the corresponding mutex. but still it will not solve the problem because if the thread which is sending signal first acquire the mutex and send the signal whereas the thread which will be waiting on pthread_cond_wait() has not yet acquired the mutex, the signal will be lost and later when the thread will wait for pthread_cond_wait() there will be no thread sending the signal.

how can we prevent this kind of scenario and how can we assure that before sending the signal there is one thread that is waiting on it.

[wje_lf]

before sending signal by pthread_cond_signal() we have to lock the corresponding mutex

Not so. In David R. Butenhof's excellent book Programming with POSIX(R) Threads, he says this in his description of pthread_cond_signal():

Although you must have the associated mutex locked to wait on a condition variable, you can signal (or broadcast) a condition variable with the associated mutex unlocked if that is more convenient.

Even if it were required for the signaling thread to acquire the mutex, though, you need to be aware of something else. A thread which wants to wait on a condition variable must acquire the associated mutex first, as you're probably aware. But the very act of waiting on the condition variable releases the mutex. From Butenhof's description of pthread_cond_wait():

When a thread waits on a condition variable it must always have the associated mutex locked. Remember that the condition variable wait operation will unlock the mutex for you before blocking the thread, and it will relock the mutex before returning to your code.

But the heart of the problem here is how you wait on a condition variable. Let's say, for example, that a worker thread is waiting for work to do, and a condition variable is used to indicate that work is available. The steps are these:

1. Lock the mutex associated with the condition variable.
2. Test the predicate. If it's already "true" (that is, if work is available), then don't do a pthread_cond_wait(); just go ahead and consume the work request. You've already locked the mutex, remember.
3. But if it's "false" (that is, if work is not yet available), then do the pthread_cond_wait(). It won't be possible for someone else to request work between the time you do the test and the time you wait, because you locked the mutex before you did the test.
4. When you come back from the pthread_cond_wait(), you still ("again", actually) have the mutex locked. So test the condition again, to make sure you really have work. Butenhof goes on for about a page about why this retesting is really necessary.
5. If you don't have work after all, go back to step 3.

This way, if there's no waiting thread when the signaling is done, it doesn't matter, because very shortly a "waiting" thread will lock the mutex, test the condition, discover that there's work to be done, and do it, without bothering to wait.

Hope this helps.

[amit_ambitions]

Hello Sir,

First of all thanks alot for your kind and wonderful reponse. Well I was aware that for signalling we need not to wait for mutex but if we do not do so probably we will again find some problem.

As you quoted correctly that we should retest the condition, I do agree with that and thanks alot for that. This is the area of problem and if we do not retest the condition we can caught in forever wait().

I have one request, do you have any onlien copy of the "programming in pthreads" book, if so lz send it to me.

I have one more question:

I read somewhere that Operating system is the entity who schedules the threads, but some people says Operating system knows only the processes and threads are created within the processes so how does OS do the scheduling.

Also if you can share some good materials for multithreading I will be gratefull to you.

[wje_lf]

do you have any onlien copy of the "programming in pthreads" book

I do not. It's well worth the money. My copy of a different book published by O'Reilly isn't inaccurate, but POSIX threads programming is really tricky, so the extra depth in the book I recommended (published by Addison Wesley) makes the O'Reilly book seem dangerous by comparison.

If you intend to do much POSIX threads programming, I consider Butenhof's book to be an absolute requirement.

Operating system is the entity who schedules the threads, but some people says Operating system knows only the processes and threads are created within the processes so how does OS do the scheduling.

Different operating systems handle this in different ways. One way is to have all the threads run as part of the same process. The operating system schedules that process when it wants to. The runtime POSIX threads library used by the program decides how to coordinate the running of all the threads within that process.

Another way is to have one thread per process. From the application programmer's point of view, it seems like one process, and the runtime POSIX threads library used by the program makes it seem that way. A few more details can be found here.

share some good materials for multithreading

The Butenhof book would be pretty much it. I haven't seen anything else that would be worth the time to read.

[amit_ambitions]

Hi,

Thanks a lot for the reply.

How does linux deals with multiple threads created by the same process and how doe it schedules them.

[wje_lf]

How does linux deals with multiple threads created by the same process and how doe it schedules them.

For brief answers, read the links I've already provided.

I don't know thorough answers. For thorough answers, read the glibc and kernel code.