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: Florian Weimer <fweimer at redhat 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: Mon, 15 Sep 2014 16:38:56 +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> <5416E04B dot 1090003 at redhat dot com>
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.