From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-19 17:26:49
--- In boost_at_[hidden], jsiek_at_l... wrote:
> Wow, quite a flurry about CVs :) Been on the road the last two
days...
>
> About the CV problem... I don't think there is a problem. The
calling
> thread does not have to own the mutex to call notify(), at least it
> doesn't in pthreads. From the POSIX standard, p.1045:
>
> "The pthread_cond_broadcast() or pthread_cond_signal() function
> may be called by a thread whether or not it currently owns the
> mutex that threads calling pthread_cond_wait() or
> pthread_cond_timedwait() have associated with the condition
> variable during their waits"
>
> In addition, I've read that calling notify() outside of the
> critical section can decrease unwanted contention.
> In "Multithreaded programming with Pthreads", p.98:
>
> "The most obvious solution for at least some of this problem
> is to make the call to signal or broadcast outside of the
> critical section. This is what all of our code does."
I'm not an expert on pthreads. Everything that I do know comes from
Pthreads Programming, O'Reilly & Associates, Inc. (a Nutshell book).
To quote them, from page 82:
"It all sounds complicated, but what if the mutex and the condition
variable weren't linked? If the condition were signaled without a
mutex, the signaling thread might signal the condition before the
waiting thread begins waiting for it -- in which case the waiting
thread would never wake up."
> Perhaps the problem came from how you were implementing CVs
> on Win32?
The implementation I have is based on the implementation designed by
Douglas Schmidt (sp?) for the ACE framework. He's one of the leading
authorities on this subject. There is a definate race condition in
this implementation if the external mutex isn't locked during the
call to notify().
Sounds like this is a non-issue for pthreads, at least according to
the quote you gave from the standard. I must admit to be confused on
this subject now, though. :(