Aaron Bannert wrote: >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. >
Sounds good to me. Thanks, --Brian
