Re: cvs commit: httpd-2.0/server/mpm/experimental/threadpool threadpool.c

[Brian Pane <bp...@pacbell.net>]

aaron@apache.org 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.

--Brian

Re: cvs commit: httpd-2.0/server/mpm/experimental/threadpool threadpool.c

[Brian Pane <bp...@pacbell.net>]

Aaron Bannert wrote:

>On Sun, Apr 28, 2002 at 02:52:39PM -0700, Brian Pane wrote:
>
>>aaron@apache.org 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

Re: cvs commit: httpd-2.0/server/mpm/experimental/threadpool threadpool.c

[Aaron Bannert <aa...@clove.org>]

On Sun, Apr 28, 2002 at 02:52:39PM -0700, Brian Pane wrote:
> aaron@apache.org 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