Re: [RFC] Propose fix for race conditions in pthread cancellation (bz#12683)

[Torvald Riegel <triegel at redhat dot com>]

On Fri, 2014-09-12 at 17:33 +0000, Joseph S. Myers wrote:
> On Fri, 12 Sep 2014, Torvald Riegel wrote:
> 
> > I believe we can still avoid sending the signal with the new scheme;
> > what we'd have to do is let the code for cancellable syscalls mark
> > (using atomic ops) whether it's currently executing or not (ie,
> > fetch_and_set to true and fetch_and_set to previous value); then the
> > pthread_cancel should see whether it needs to send a signal or not.
> > That adds a bit more synchronization, but seems possible.
> 
> Would this be calling C functions that do those atomic operations (in 
> similar places to where there are currently calls to 
> __pthread_enable_asynccancel etc.)?  That would seem better than embedding 
> the atomic operation code directly in the macros that generate .S syscall 
> stubs, at least for architectures where there are multiple variants for 
> how atomic operations are implemented depending on things such as the 
> architecture version.

I haven't thought it through, but this should be possible I guess.  What
we want is to have an optimization "around" the new scheme, where both
the cancellation target and the cancellation initiator agree that they
got canceled.  The agreement would be a CAS or atomic_exchange, and we
might have to use pthread_testcancel when we find out we were canceled.
That would mean we have this check twice (IIRC, the new scheme's asm
code has it at the beginning of the region), but still might be better.