Condition Variable
nvi...@nospam.hotmail.com
I've got a trivial question (but one which kepot me thinking a bit)
Is there any reason for signalling a condition variable and then
unlocking a mutex. What would happen if we unlock the mutex and then
signal a condition variable? Is this a mere convention?
What does signalling a condition variable actually do... please explain
this from the run-time thread manager's point of view.
Thanks,
Vivek
Rajanish Calisa
<nvi...@NOSPAM.hotmail.com> wrote in message
news:3A3D2E7F...@NOSPAM.hotmail.com...
>
> Is there any reason for signalling a condition variable and then
> unlocking a mutex. What would happen if we unlock the mutex and then
> signal a condition variable? Is this a mere convention?
>
acquiring
the mutex. See the example pseudo code below.
Correct Usage:
lock_mutex ;
modify data
unlock_mutex ;
cond_signal ;
Wrong Usage:
modify_data;
cond_signal
I rememberreading somewhere that if signalling is done when the lock is
held,
one gets predictable scheduling. I am not sure what that means in practical
terms. Other members of the group might elaborate on that.
raj...
Kaz Kylheku
<nvi...@NOSPAM.hotmail.com> wrote:
>Hello there,
>
>I've got a trivial question (but one which kepot me thinking a bit)
>
>Is there any reason for signalling a condition variable and then
>unlocking a mutex.
No.
>What would happen if we unlock the mutex and then
>signal a condition variable?
What could happen is that some thread can sneak into the mutex before that
happens without being signaled and then the signal goes to some other thread,
causing a spurious wakeup. Whereas signaling in the mutex can cause somewhat
more predictable behavior.
Is this a mere convention?
>
>What does signalling a condition variable actually do... please explain
>this from the run-time thread manager's point of view.
It can't be explained from that point of view; you'd first have to explain
exactly what kind of run time thread manager you have. It's best explained
in terms of abstract semantics.
Signaling a condition variable simply causes a thread that is waiting on that
condition variable to wake up. The only chicanery is in the wait operation
which unlocks the mutex and then causes the thread to wait on the condition
variable. This operation has the special property that any other thread
which gets that mutex and then signals that condition variable (either before
or after releasing the mutex) cannot deliver that signal before the original
thread is actually waiting for it.
In other words, the following erroneous sequence of operations is ruled out:
Thread A Thread B
predicate found false
release mutex
get mutex
makes predicate true
release mutex
signal condition (nobody waiting, lost signal)
wait on condition
The implementation must ensure, using any means possible, that thread B's
signal is not lost in this case, so that it's possible for thread A to
wake up because of it.
Whether the mutex is released by B before or after the signal is irrelevant;
it's B's acquisition of the mutex that is crucial, not the release. If thread
B signals without locking the mutex first, then it's no longer assured that the
signal cannot be missed, because it's not sychronized in any way with the
actions of thread A.
Øyvind Bakksjø
>
> On Sun, 17 Dec 2000 15:22:07 -0600, nvi...@NOSPAM.hotmail.com
> <nvi...@NOSPAM.hotmail.com> wrote:
> >Hello there,
> >
> >I've got a trivial question (but one which kepot me thinking a bit)
> >
> >Is there any reason for signalling a condition variable and then
> >unlocking a mutex.
>
> No.
If you write:
lock(mutex);
signal(condvar);
unlock(mutex);
in thread A, and you have a thread B waiting on condvar, will signal()
cause thread B to wake up, try to acquire the mutex, sleep, then (at
some point in time) thread A is activated again, releases the mutex, and
(at another point in time) thread B is scheduled and can lock the mutex?
The desired handling would be to continue running thread A after doing
signal(), so that it could unlock the mutex before thread B woke up.
I know POSIX states nothing about this (since this has nothing to do
with the interface), but how is it on a typical implementation? Is it
less efficient to signal from within the mutex?
--
Øyvind Bakksjø
sa...@bear.com
k...@ashi.footprints.net wrote:
> On Sun, 17 Dec 2000 15:22:07 -0600, nvi...@NOSPAM.hotmail.com
> <nvi...@NOSPAM.hotmail.com> wrote:
> >Hello there,
> >
> >I've got a trivial question (but one which kepot me thinking a bit)
> >
> >Is there any reason for signalling a condition variable and then
> >unlocking a mutex.
[very good explanation snipped]
> In other words, the following erroneous sequence of operations is
ruled out:
>
> Thread A Thread B
>
> predicate found false
> release mutex
> get mutex
> makes predicate true
> release mutex
> signal condition (nobody waiting, lost signal)
>
> wait on condition
>
[snipped]
> If thread
> B signals without locking the mutex first, then it's no longer
assured that the
> signal cannot be missed, because it's not sychronized in any way with
the
> actions of thread A.
>
Is the lost-wakeup not a big problem?
The HP-UX man page for pthread_cond_signal also says:
The pthread_cond_signal() or pthread_cond_broadcast() functions can be
called by a thread whether or not it currently owns the condition
variable's associated mutex. For predictable scheduling behavior and
to prevent lost wake-ups, the mutex should be held when signaling a
condition variable.
In what situations do you not care about lost wake-ups?
Thank you,
Saroj Mahapatra
Sent via Deja.com
http://www.deja.com/
Dave Butenhof
> Is the lost-wakeup not a big problem?
>
> The HP-UX man page for pthread_cond_signal also says:
>
> The pthread_cond_signal() or pthread_cond_broadcast() functions can be
> called by a thread whether or not it currently owns the condition
> variable's associated mutex. For predictable scheduling behavior and
> to prevent lost wake-ups, the mutex should be held when signaling a
> condition variable.
This is stupid. The only way you can lose a wakeup is if you're using the
condition variable improperly; and signalling "under" the mutex won't solve
that problem. (Not by itself anyway; and if you fix the code so it'll work
that way, it'll also work if you signal "outside" the mutex.)
Lost wakeups can only happen when you don't use a predicate...
T1 T2
---------------------------- ---------------------------
pthread_mutex_lock (&m); pthread_cond_signal (&c);
pthread_cond_wait (&c, &m);
pthread_mutex_unlock (&m);
The signal happened while T1 wasn't yet waiting, so it does nothing. The
wait will then block "forever" (or until "c" is next signalled). This is
true whether or not T2 locks the mutex. Though having T2 lock the mutex
would force the signal to occur either before T1 locks the mutex or after
it's unlocked it (one way or another), signalling before the lock is just
as bad as the picture above: there's no waiter, and it does nothing, and
the wait blocks "forever".
With a predicate, as required by mutex/condition-variable semantics,
there's no problem. Regardless of whether you signal "under" the mutex, the
predicate is shared data, and the predicate change must always be protected
by the mutex:
T1 T2
---------------------------- ---------------------------
pthread_mutex_lock (&m);
predicate = TRUE;
pthread_mutex_unlock (&m);
pthread_mutex_lock (&m); pthread_cond_signal (&c);
while (!predicate)
pthread_cond_wait (&c, &m);
pthread_mutex_unlock (&m);
T2 is now constrained to set the predicate either after T1 is blocked in
wait (in which case the signal will awaken it) or before T1 locks the mutex
(in which case the predicate test will see that it doesn't need to wait).
The timing of the call to pthread_cond_signal() is more or less irrelevant
here: either it awakens the waiter, or it doesn't NEED to do anything.
(Which is precisely why the standard says that a signal without waiters
doesn't do anything.)
> In what situations do you not care about lost wake-ups?
In those situations in which proper or predictable behavior of the program
is irrelevant?
/------------------[ David.B...@compaq.com ]------------------\
| Compaq Computer Corporation POSIX Thread Architect |
| My book: http://www.awl.com/cseng/titles/0-201-63392-2/ |
\-----[ http://home.earthlink.net/~anneart/family/dave.html ]-----/
sa...@bear.com
Dave Butenhof <David.B...@compaq.com> wrote:
> sa...@bear.com wrote:
>
> > Is the lost-wakeup not a big problem?
> >
> > The HP-UX man page for pthread_cond_signal also says:
> >
> > The pthread_cond_signal() or pthread_cond_broadcast() functions can
be
> > called by a thread whether or not it currently owns the condition
> > variable's associated mutex. For predictable scheduling behavior
and
> > to prevent lost wake-ups, the mutex should be held when signaling a
> > condition variable.
>
> This is stupid. The only way you can lose a wakeup is if you're using
the
> condition variable improperly; and signalling "under" the mutex won't
solve
> that problem.
[snipped]
Thank you for clarifying the HP-UX man page. I have always
signaled without holding a mutex knowing that a `less' predictable
scheduling might result, but I was not prepared for a lost-wakeup.
- Saroj Mahapatra
Kaz Kylheku
>Thank you for clarifying the HP-UX man page. I have always
It could well be that the HP-UX man page accurately describes the state of the
HP-UX implementation. I'd be suspicious. If the same developer wrote the man
page and the mutex and condition functions, look out! ;)
Joe Seigh
>
> Hello there,
>
> I've got a trivial question (but one which kepot me thinking a bit)
>
> Is there any reason for signalling a condition variable and then
> unlocking a mutex. What would happen if we unlock the mutex and then
> signal a condition variable? Is this a mere convention?
>
some thread waiting on the condtion variable would be more likely to be
the next thread to acquire the mutex if the signal was done while holding
the mutex.
> What does signalling a condition variable actually do... please explain
> this from the run-time thread manager's point of view.
>
There's a posting further down in this newgroup on implementations of condition variables
with a good answer by David Butenhof.
Joe Seigh
Dave Butenhof
Yes, that thought had crossed my mind as well. But I prefer to let someone else
bad-mouth a competitor's implementation. (So, thanks. ;-) )