[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140808191405.GP1674@brightrain.aerifal.cx>
Date: Fri, 8 Aug 2014 15:14:06 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Explaining cond var destroy [Re: C threads, v3.0]
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
