Re: The semantics of pthread_cond_wait

[Richard Braun]

On Wed, Aug 15, 2012 at 05:47:47PM -0700, Thomas DiModica wrote:
> My understanding is that pthread_cond_wait is a cancellation point.
> It achieves this by entering asynchronous cancellation mode before blocking.
> 
> I don't see, however, any code that checks for a pending cancellation when
> we enter the function. As far as I can tell, the implementation is that
> pthread_cond_wait is a cancellation point if and only if the thread is
> canceled while it is blocked.

It seems so, yes.

> Right now, I can't think of any solution involving checking for cancellation
> that doesn't include a potential gap between checking for cancellation and
> entering asynchronous cancellation mode.

My opinion is that the implementation shouldn't rely on switching to
async mode, and rather add explicit cancellation tests. This would
require pthread_cancel be modified to wake the target thread in deferred
mode.

> PS Non-informative: setcanceltype in the cleanup function appears to
> be in the wrong place. Shouldn't it be the first thing to happen? Spin lock
> and spin unlock aren't async-cancel-safe, right? So, if we are in cleanup,
> lock the lock, and someone cancels us: async-cancellation injects a
> call to pthread_exit, where we call cleanup again and deadlock trying
> to lock a lock we hold.

That's not possible. The cleanup function is called from pthread_exit,
which disables cancellation, whichever type is set. This call in the
cleanup callback is meant to restore the type on entry in case no
cancellation occurred.

-- 
Richard Braun