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
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
