On Thu, 22 Sep 2016, Waiman Long wrote: > On 09/22/2016 09:34 AM, Thomas Gleixner wrote: > > On Thu, 22 Sep 2016, Peter Zijlstra wrote: > > > > > > I'd leave out the TO part entirely (or only mention it in changelogs). > > > > > > That is, I'd call the futex ops: FUTEX_LOCK and FUTEX_UNLOCK. > > That brings me to a different question: > > > > How is user space going to support this, i.e. is this some extra magic for > > code which implements its own locking primitives or is there going to be a > > wide use via e.g. glibc. > > There are some applications that use futex(2) directly to implement their > synchronization primitives. For those applications, they will need to modify > their code to detect the presence of the new futexes. They can then use the > new futexes if available and use wait-wake futexes if not. That's what I suspected. Did you talk to the other folks who complain about futex performance (database, JVM, etc.) and play their own games with user space spinlocks and whatever? > I am also planning to take a look at the pthread_mutex* APIs to see if they > can be modified to use the new futexes later on when the patch becomes more > mature. Please involve glibc people who are interested in the futex stuff early and discuss the concept before it's set in stone for your particular usecase. > > Also what's the reason that we can't do probabilistic spinning for > > FUTEX_WAIT and have to add yet another specialized variant of futexes? > > > > The main reason is that a FUTEX_WAIT waiter has no idea who the owner of the > futex is. We usually do spinning when the lock owner is running and abort when > it goes to sleep. We can't do that for FUTEX_WAIT. Fair enough. This wants to be spelled out in the changelog and explained a bit more detailed. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
