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

[Torvald Riegel]

On Mon, 2014-09-15 at 14:49 +0200, Florian Weimer wrote:
> On 09/10/2014 11:47 PM, Adhemerval Zanella wrote:
> > Anyway, now I would like comments about proposed solution and if the cases for
> > new failures should not be allowed or if testcases now should be adjusted.
> 
> Will it be possible to use this mechanism to make selected lock-free 
> algorithms inside glibc async-signal-safe?

Not without additional care, I suppose.  Lock freedom allows the other
threads to make progress, but the thread itself can still do blocking
operations as long as it doesn't communicate with other threads in the
meantime; so, for example, there could be other random blocking stuff
embedded in a lock-free algorithm.

> I think rewinding to a 
> previous address will be sufficient in many cases, but a more general 
> approach which completes execution of a critical section in the signal 
> handler could be desirable.

That would require more care than just having a lock-free algorithm as
far as communication with other threads is concerned, because the
interruptible code than *also* needs to be lock-free wrt. the
continuation / fix-up code in the signal handler.  While this may not
need HW synchronization, the compiler still needs to be aware of this.