On Sun, Apr 28, 2002 at 02:52:39PM -0700, Brian Pane wrote:
> [EMAIL PROTECTED] wrote:
>
> >aaron 02/04/28 14:35:13
> >
> > Modified: server/mpm/experimental/threadpool threadpool.c
> > Log:
> > When we signal a condition variable, we need to own the lock that
> > is associated with that condition variable. This isn't necessary
> > for Solaris, but for Posix it is.
> >
>
> Is it really required for Posix compliance, or just recommended
> as a standard idiom for guaranteeing that the target thread is
> actually waiting on the condition variable? I thought it was
> the latter; if so, in threadpool and leader/follower the
> lock/unlock/signal idiom should be safe.
Actually, it isn't required for Posix, but that's not the whole story.
Here's what Stevens says on p. 170-171 of UNIX Network Programming:
Interprocess Communication, Vol 2, 2nd Ed:
Here we do not signal the condition variable until we release the
mutex. This is explicitly allowed by Posix: the thread calling
pthread_cond_signal need not be the current owner of the mutex
associated with the condition variable. But Posix goes on to say
that if predictable scheduling behavior is required, then the mutex
must be locked by the thread calling pthread_cond_signal.
So you are correct, but I think we should be safe here, especially
considering that we required the lock followed by an immediate unlock
to get proper behavior, right? I'll alter the comment to be correct,
and include a reference to Stevens in there too.
-aaron
