[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The semantics of pthread_cond_wait

From: Richard Braun
Subject: Re: The semantics of pthread_cond_wait
Date: Thu, 16 Aug 2012 11:48:35 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

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

> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]