On Wed, 2 May 2018, Peter Zijlstra wrote: > On Wed, May 02, 2018 at 06:27:22PM +0000, Daniel Colascione wrote: > > On Wed, May 2, 2018 at 10:22 AM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > >> On Wed, May 02, 2018 at 03:53:47AM +0000, Daniel Colascione wrote: > > > > Suppose we make a userspace mutex implemented with a lock word having > > three > > > > bits: acquired, sleep_mode, and wait_pending, with the rest of the word > > not > > > > being relevant at the moment. > > > > > So ideally we'd kill FUTEX_WAIT/FUTEX_WAKE for mutexes entirely, and go > > > with FUTEX_LOCK/FUTEX_UNLOCK that have the same semantics as the > > > existing FUTEX_LOCK_PI/FUTEX_UNLOCK_PI, namely, the word contains the > > > owner TID. > > > > That doesn't work if you want to use the rest of the word for something > > else, like a recursion count. With FUTEX_WAIT and FUTEX_WAKE, you can make > > a lock with two bits. > > Recursive locks are teh most horrible crap ever. And having the tid in > the word allows things like kernel based optimistic spins and possibly > PI related things. FWIW, robust futex have also the TID requirement. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
