Hello everyone,


Suppose several threads are trying to enter into a region, which is protected by a mutex to allow only one thread in such region, and then one of them is luckily selected to enter into the region while others are locked from entering the region.

Suppose sometime later, the lucky thread exits the region, and then without calling pthread_cond_signal, simply calling unlock (as the last statement) to exit the region. I am wondering whether the waiting locked thread will know the status -- the mutex is unlocked and it is ready for a thread to try to enter the region -- immediately. If not, it seems that the waiting threads will continue to wait so that the performance is not very good.

I am sure that calling pthread_cond_signal will let the waiting locked threads know immediately the status, but not sure what will happen if we do not call pthread_cond_signal and simply call unlock, as I mentioned above.

Could anyone help please?


regards,
George

It depends if it all runs on one or more processes. If there are more, there's still a huge chance all the threads will be running on one, but it may be different. Now, when they're all using one processor, there's only one thread running at a time. So the other ones may 'notice' the change only when they're run. By scheduler, after the one running is stopped (whatever reason). I don't remember at this time if unclock runs scheduler. It may.

Thanks Mara,


Your reply is very helpful. I am wondering why "So the other ones may 'notice' the change only when they're run". Why only when?

So your point is that it is not sure that whether or not calling pthread_cond_signal will be more efficient than not calling it when a thread unlocks a region. But if unlock runs scheduler, it will be the same. Am I correct?

I am wondeirng whether the activities of unlock and pthread_cond_signal, which I am concerning on this topic, is standard or formally documented anywhere.


regards,
George

If another thread is waiting for the mutex to be unlocked, it will wake-up when the unlock occurs. If no one is waiting for the mutex, no one knows (or, presumably, cares...) that the mutex has just been unlocked.

The purposes of a condition variable and that of a mutex are not the same. A condition-variable is a sentinel that indicates, to anyone who may be waiting for it, that "something interesting may have just happened." A mutex is a locked room that allows only one process to enter at a time.

I say "may have" just happened because it is possible that a process will wait for the condition and find out that there is not, in fact, anything for it to do. But that's okay. We don't mind if the process winds up taking a few extra, empty cycles. What we don't want to allow is "infinite wait," or deadlock, where everyone is Waiting For Godot.

It is often the case that there is a thread which performs services asynchronously for other threads, using some shared control-block to (say) describe the next request or to maintain a queue of pending requests. This thread will use a mutex to synchronize access to the control-block (which must be accessed both by the server and by requestors), and a condition-variable to signal to the server that there might be more work for it to do. When the server finishes a request and wants to wait for more, pthread_cond_wait() is exactly the sort of sequence that the server needs to do, and this call binds the usual three-step sequence up neatly in just one call instead of three.

Thanks sundialsvcs,




Your reply is very helpful. So you mean when a thread calling unlock mutex, whether or not calling pthread_cond_signal, the waiting threads on the mutex will be notified immediately. Am I correct? I am wondering whether this feature is documented in any pthread standards or formal documents.

Quote:

Originally posted by sundialsvcs The purposes of a condition variable and that of a mutex are not the same. A condition-variable is a sentinel that indicates, to anyone who may be waiting for it, that "something interesting may have just happened." A mutex is a locked room that allows only one process to enter at a time. I say "may have" just happened because it is possible that a process will wait for the condition and find out that there is not, in fact, anything for it to do. But that's okay. We don't mind if the process winds up taking a few extra, empty cycles. What we don't want to allow is "infinite wait," or deadlock, where everyone is Waiting For Godot.

A very good description! What do you mean "find out that there is not, in fact, anything for it to do" and "winds up taking a few extra, empty cycles"? Could you provide a simple sample please?

Quote:

Originally posted by sundialsvcs It is often the case that there is a thread which performs services asynchronously for other threads, using some shared control-block to (say) describe the next request or to maintain a queue of pending requests. This thread will use a mutex to synchronize access to the control-block (which must be accessed both by the server and by requestors), and a condition-variable to signal to the server that there might be more work for it to do. When the server finishes a request and wants to wait for more, pthread_cond_wait() is exactly the sort of sequence that the server needs to do, and this call binds the usual three-step sequence up neatly in just one call instead of three.

I think it is a very typical model in almost all software design. I want to reuse this model in the future. Do you know where can I find simple sample source codes of this model? Any programming language is ok.


regards,
George

When you unlock a mutex, if there are other threads that are waiting for this mutex to be unlocked, the first-in-line thread will be awakened. Otherwise nothing more happens.

A condition-variable simply serves to wake-up someone who's waiting on it... to get them out of their sleep and to start them running again. Another way of looking at them is rather in-reverse: a condition-variable is a construct that exists in order to enable a thread to reliably sleep during the times that it is known that it does not have any work to do.

Thanks sundialsvcs,


Your reply is very helpful. What do you mean "first-in-line thread"? Could you provide me a simple sample please?


regards,
George

It's a queue, okay? A waiting-list. The first guy in line gets to go. The rest continue to wait. Just like in the real world.

Thanks sundialsvcs,


Your reply is very helpful.

I am sorry that I have not made myself understood. My question is not whether waiting threads will be awaken up to proceed. My queston is that,

1. Calling both pthread_mutex_unlock and pthread_cond_signal will let the waiting locked threads know immediately the status. Am I correct?
2. What will happen if we do not call pthread_cond_signal and simply call pthread_mutex_unlock? Will the waiting threads know immediately about the status (can proceed to execution)?


regards,
George