It's written in POSIX threads tutorial https://computing.llnl.gov/tutorials/pthreads/ that it is a logical error.
my question is why it is a logical error?
In my program i need to use these signals, however i cannot guarantee that there will be a thread that will be in _cond_wait state. I tried to test it and nothing happens. Is this can cause unexpected behavior or worse?
thank you!
The answer of blaze comes closest, but is not totally clear:
conditional variables should only be used to signal a change in a condition.
Thread 1 checks a condition. If the condition doesn't meet, he waits on the condition variable until the condition meets. Because the condition is checked first, he shouldn't care whether the condition variable was signaled:
pthread_mutex_lock(&mutex);
while (!condition)
pthread_cond_wait(&cond, &mutex);
pthread_mutex_unlock(&mutex);
Thread 2 changes the condition and signals the change via the condition variable. He doesn't care whether threads are waiting or not:
pthread_mutex_lock(&mutex);
changeCondition();
pthread_mutex_unlock(&mutex);
pthread_cond_signal(&cond)
The bottom line is: the communication is done via some condition. A condition variable only wakes up waiting threads so they can check the condition.
Examples for conditions:
see also pthread example
pthread_cond_wait() call where the mutex is unlocked. That's why the mutex has to be passed to this call. So thread 2 only needs to wait when thread 1 is actually checking the condition. This is what the mutex is for: protecting the resources that make up the condition.. –
Vibrant startThread() function exited immediately when the thread was started, but had not yet entered pthread_cond_wait. If I called stopThread() immediately and inside it I set predicate=true; pthread_cond_signal(), then my thread did not wake up because the signal came too early. Now I will know that it's by design and I should not set cond_signal when I'm not sure if a thread is waiting for it. A workaround was simple - check for the predicate once in the thread loop before entering pthread_cond_wait. –
Bull while (!condition). A nice example is the thread-shared queue where the receiving thread waits for the queue to be non-empty so it can consume the next entry in the queue. –
Vibrant My 2 cents: I do not know the side effects of calling *pthread_cond_signal()* when no thread has been blocked calling *pthread_cond_wait()*. This is really an implementation detail What I think is that, if your threading/timimg model do not guarantee the rigth order between wait and signal, probably you should consider a different sync mechanism [like a simple semaphore, for example] when you can signal the semaphore from thread B even if the thread A has nor reached the sync point. When thread A will reach the sync point, it will find the semaphore incremented and will enter the critical session.
I write my answer because I do not see the one that will calm people. I also stumbled upon that bizarre disturbing warning about “logical error” in that tutorial. Note that there is nothing about this “error” in the POSIX documentation article on pthread_cond_signal. I am sure that this is an unfortunate choice of the term or a plain mistake on part of the author of the tutorial. Their claim may be interpreted as if a process will terminate with an error in this situation or that any program permitting this situation is incorrect. Nothing of the sort is true. Such situations are common. The documentation says that
The
pthread_cond_signal()andpthread_cond_broadcast()functions have no effect if there are no threads currently blocked oncond.
So don't worry and be happy.
pthread_cond_signal which is also not true. –
Vibrant A condition variable allows one thread to wake another up from a wait. They work only if there is a thread waiting at the moment when you trigger the condition. The way to ensure that this is the case is for the waiting thread to lock a mutex which is linked to the condition, and for the signalling thread to lock that mutex before triggering the condition. In other words, the signalling thread can only lock the mutex and trigger the condition if the other thread had the mutex locked but is now waiting.
I'm most familiar with boost, so I'll use that in this example:
// A shared mutex, global in this case.
boost::mutex myMutex;
// Condition variable
boost::condition_variable myCondition;
void threadProc()
{
// Lock the mutex while the thread is running.
boost::mutex::scoped_lock guard( myMutex );
while( true )
{
// Do stuff, then...
myCondition.wait( guard ); // Unlocks the mutex and waits for a notification.
}
}
void func()
{
// Function wants to trigger the other thread. Locks the mutex...
boost::mutex::scoped_lock guard( myMutex );
// Since the mutex is locked, we know that the other thread is
// waiting on the condition variable...
myCondition.notify_all();
}
To signal a condition variable when there is no corresponding wait is a logical error because nothing will ever receive the signal. Condition variables don't remain in a signalled state.
If you do not care that this signal will be lost - there is no error. It is only an error if you expect later coming waiting thread to wake from cond_wait() immediately.
Since this is usual use case for pthread_cond, tutorial calls this logical error. But nothing will crash and no unexpected behavior will occur. In normal execution flow cond_signal() still may be issued when there is no threads in cond_wait(): f.e., all readers may be just doing message processing when writer adds another data piece in queue.
© 2022 - 2024 — McMap. All rights reserved.