This is the mail archive of the 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] mutex destruction (#13690): problem description and workarounds

On Fri, Apr 04, 2014 at 04:20:30PM +0200, Torvald Riegel wrote:
> === Workaround 1a: New FUTEX_WAKE_SPURIOUS operation that avoids the
> specification change
> This is like Workaround 1, except that the kernel could add a new futex
> op that works like FUTEX_WAKE except that:
> * FUTEX_WAITs woken up by a FUTEX_WAKE_SPURIOUS will always return
> EINTR.  EINTR for spurious wakeups is already part of the spec, so
> correct futex users are already handling this (e.g., glibc does).
> * Make sure (and specify) that FUTEX_WAKE_SPURIOUS that hit other
> futexes (e.g., PI) are ignored and don't cause wake-ups (or just benign
> spurious wakeups already specified).
> Users of FUTEX_WAKE_SPURIOUS should have to do very little compared to
> when using FUTEX_WAKE.  The only thing that they don't have anymore is
> the ability to distinguish between a real wakeup and a spurious one.
> Single-use FUTEX_WAITs could be affected, but we don't have them in
> glibc.  The only other benefit from being able to distinguish between
> real and spurious is in combination with a timeout: If the wake-up is
> real on a single-use futex, there's no need to check timeouts again.
> But will programs want to use this often, and will they need to have to
> use FUTEX_WAKE_SPURIOUS in this case?  I guess not.
> Pros:
> * Correct futex uses will need no changes.
> Cons:
> * Needs a new futex operation.

I'm fine with this except for the return value. EINTR should never
mean anything but "interrupted by signal". Especially if we're going
to be exposing futex() to applications as a public API, which should
be done, applications should be able to rely on EINTR always being
"interrupted by signal" in the sense that it's acceptable to assume it
doesn't happen if you're not using (interrupting) signal handlers and
that it's okay to use a standard EINTR retry loop if you want to. This
would not be valid if EINTR were overloaded with the above meaning.

There are plenty of other errno codes that could be used without
creating this problem. EINPROGRESS has good precedent as a "non-error"
error condition, and seems like a reasonable choice, but I'm fine with
anything that doesn't overload EINTR or other existing errors in ways
that would break existing handling.

> === Workaround 4: Only use futexes in non-reused memory.

This does not work for process-shared objects. There is no mechanism
for allocating such memory that all processes with access to the sync
object can access, and which other processes which should not have
access cannot access.


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