Linux provides a sys futex() system call to assist in implementing hybrid user-level/kernel-level locks and condition variables. A call to long sys futex(void *addr1, FUTEX WAIT, int val1, NULL, NULL, 0 checks to see if the memory at address addr1 has the same value as val1. If so, the calling thread is suspended. If not, the calling thread returns immediately with the error return value EWOULDBLOCK. In addition, the system call will return with the value EINTR if the threadreceives a signal. A call to long sys futex(void *addr1, FUTEX WAKE, 1, NULL, NULL, 0) causes one thread waiting on addr1 to return. Consider the following (too) simple implementation of a hybrid userlevel/kernel-level lock. class TooSimpleFutexLock { private : int val ; public : TooSimpleMutex () : val (0) { } // Constructor void Acquire () { int c; while (( c = atomic_inc ( val )) != 0){ // atomic_inc returns * old* value futex_wait (& val , c + 1); } } void Release () { val = 0; futex_wake (& val , 1); } }; There are three problems with this code. (a.) Peformance. The goal of this code is to avoid making (expensive) system calls in the uncontested case when an Acquire() tries to acquire a free lock or a Release() call releases a lock with no other waiting threads. This code fails to meet this goal. Why? (b.) Performance. There is a subtle corner case when multiple threads try to acquire the lock at the same time that can show up as occasional slowdowns and bursts of CPU usage. What is the problem? (c.) Correctness. There is a corner case that can cause the mutual exclusion correctness condition to be violated, allowing two threads to both believe they hold the lock. What is the problem?