From 8e754e12c57f14323371cb84ddc43700109c21f0 Mon Sep 17 00:00:00 2001 From: Heinrich Schuchardt Date: Sun, 29 Mar 2015 21:13:03 +0200 Subject: [PATCH] futex.2: explanation of blocking Use shorter sentences. Signed-off-by: Heinrich Schuchardt Signed-off-by: Michael Kerrisk --- man2/futex.2 | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/man2/futex.2 b/man2/futex.2 index dea50ea46..6a4d45c25 100644 --- a/man2/futex.2 +++ b/man2/futex.2 @@ -85,14 +85,18 @@ In the uncontended case, a thread can access or modify the lock state with atomic instructions, for example atomically changing it from not acquired to acquired using an atomic compare-and-exchange instruction. -If a thread cannot acquire a lock because -it is already acquired by another thread, -it can request to block if and only the lock is still acquired by -using the lock's flag as futex word and expecting a value that -represents the acquired state. +A thread maybe unable acquire a lock because +it is already acquired by another thread. +It then may pass the lock's flag as futex word and the value +representing the acquired state as expected value to a +.BR futex () +wait operation. +.BR futex () +will block if and only if the lock is still acquired. When releasing the lock, a thread has to first reset the -lock state to not acquired and then execute the futex operation that -wakes one thread blocked on the futex word that is the lock's flag +lock state to not acquired and then execute a +.BR futex () +operation that wakes threads blocked on the lock flag used as futex word. (this can be be further optimized to avoid unnecessary wake-ups). See .BR futex (7)