This is the mail archive of the
mailing list for the glibc project.
Re: [RFC] Propose fix for race conditions in pthread cancellation (bz#12683)
- From: Torvald Riegel <triegel at redhat dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>, "GNU C. Library" <libc-alpha at sourceware dot org>, Rich Felker <dalias at aerifal dot cx>
- Date: Sun, 14 Sep 2014 20:04:21 +0200
- Subject: Re: [RFC] Propose fix for race conditions in pthread cancellation (bz#12683)
- Authentication-results: sourceware.org; auth=none
- References: <5410C70E dot 70207 at linux dot vnet dot ibm dot com> <1410533066 dot 4967 dot 96 dot camel at triegel dot csb> <Pine dot LNX dot 4 dot 64 dot 1409121725530 dot 1118 at digraph dot polyomino dot org dot uk>
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.