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.