Re: [RFC PATCH v2 3/5] futex: Throughput-optimized (TO) futexes

[Waiman Long]

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.

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.

> 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.

Cheers,
Longman