The man-pages as well as robust-futexes.txt use the word "contend" for a situation where two threads try to access the same futex at the same time.
To avoid confusion robust-futex-API.txt should not use "contest" as alternative language. Signed-off-by: Heinrich Schuchardt <[email protected]> --- Documentation/robust-futex-ABI.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/robust-futex-ABI.txt b/Documentation/robust-futex-ABI.txt index 16eb314..e6a5532 100644 --- a/Documentation/robust-futex-ABI.txt +++ b/Documentation/robust-futex-ABI.txt @@ -18,8 +18,8 @@ required for futexes is: by the exiting thread. The existing normal futexes already provide a "Fast Userspace Locking" -mechanism, which handles uncontested locking without needing a system -call, and handles contested locking by maintaining a list of waiting +mechanism, which handles uncontended locking without needing a system +call, and handles contended locking by maintaining a list of waiting threads in the kernel. Options on the sys_futex(2) system call support waiting on a particular futex, and waking up the next waiter on a particular futex. -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
