This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Sun, Sep 14, 2014 at 08:00:49PM +0200, Torvald Riegel wrote:
> > Actually, cancellation of pthread_cond_[timed]wait is complicated.
> > Depending on how unblocking a waiter works, it's possible that the
> > thread being cancelled has already "consumed the signal", and
> > therefore can't act on cancellation. This is a case where the program
> > counter at cancellation signal time is not sufficient to determine if
> > cancellation can be acted upon; the decision needs to be made later
> > based on userspace criteria (cond var state), not based on the
> > completion or non-completion of the futex syscall.
> 
> If something that got cancelled has consumed a signal already, then this
> isn't visible to other threads yet except that they don't wake up.  Have
> you considered sending another signal (which is indistinguishable from
> the one consumed by the cancelled thread) to undo the consumption?

It's not that simple, because it's hard to guarantee waking a waiter
from the right set. The signal that was consumed by the cancelled
thread must wake a waiter which was already a waiter at the time of
that signal, not another waiter that arrives later. There may be other
difficulties too.

Rich


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]