Re: Explaining cond var destroy [Re: [musl] C threads, v3.0]

[Rich Felker <dalias@libc.org>]

On Fri, Aug 08, 2014 at 11:20:27AM +0200, Jens Gustedt wrote:
> Hello,
> 
> Am Donnerstag, den 07.08.2014, 13:25 -0400 schrieb Rich Felker:
> > Most futex operations (including wait) access an object for read. Some
> > rarely-used ones write to an object too. Wake does neither. Wake is
> > purely an operation on the address/futex-waitqueue-object. This
> > property is not just a side effect but absolutely necessary in order
> > for futex to be useful, since you _always_ perform the futex wake
> > after releasing (and thereby potentially allowing destruction) of the
> > object.
> 
> I agree with almost all what you are saying, in particular the
> facts, ;) and your statement is a good summary of what I learned with
> our discussion.

I think I may have a solution you'll like:

We can perform the release of the lock via a compare-and-swap rather
than a simple swap. In this way, we can know before releasing the lock
whether it's going to require a wake or not:

- If waiters was zero and the cas from owned/uncontended to zero
  succeeds, no futex wake operation is needed.

- If waiters was nonzero, or if the cas fails (thereby instead
  requiring a cas from owned/contended to zero), we can do the
  following:

Don't use a userspace CAS to release; this would allow the lock to be
acquired by another thread, released, destroyed, and freed before the
futex wake is performed. Instead, use FUTEX_WAKE_OP to atomically
perform the atomic assignment and futex wake.

Do you see any problems with this approach? I think it fully solves
the problem. If there are old kernels that lack FUTEX_WAKE_OP, we
could fallback to emulating it in userspace for those (with the
spurious wake issue). I think this approach may also also allow me to
resolve an issue that's preventing me from eliminating a lot of
useless FUTEX_WAKE syscalls under certain contention patterns, but I'm
not sure yet.

Rich