futex - low-level synchronization primitive
#include <serenity.h>
// Raw syscall.
int futex(uint32_t* userspace_address, int futex_op, uint32_t value, const struct timespec* timeout, uint32_t* userspace_address2, uint32_t value3);
// More convenient wrappers.
int futex_wait(uint32_t* userspace_address, uint32_t value, const struct timespec* abstime, int clockid, int process_shared);
int futex_wake(uint32_t* userspace_address, uint32_t count, int process_shared);
The futex()
system call provides a low-level synchronization primitive,
essentially exposing the kernel's internal thread synchronization primitives
to userspace.
While the futex()
API is powerful and generic, it is complex and cumbersome
to use, and notoriously tricky to use correctly. For this reason, it is not
intended to be used by application code directly, but rather to serve as
a building block for more specialized and easier to use synchronization
primitives implemented in user space, such as mutexes and semaphores.
Specifically, the futex()
API is designed to enable userspace synchronization
primitives to have a fast path that does not involve calling into the kernel
at all in the common uncontended case, avoiding the cost of making a syscall
completely.
A futex is a single 32-bit integer cell located anywhere in the address space of a process (identified by its address), as well as an associated kernel-side queue of waiting threads. The kernel-side resources associated with a futex are created and destroyed implicitly when a futex is used; in other words, any 32-bit integer can be used as a futex without any specific setup, and a futex on which no threads are waiting is no different to any other integer. The kernel does not assign any meaning to the value of the futex integer; it is up to userspace to make use of the value for its own logic.
The futex()
API provides a number of operations, the most basic ones being
waiting and waking:
FUTEX_WAKE
/ futex_wake()
: wake up to count
threads waiting on the
futex (in the raw futex()
syscall, count
is passed as the value
argument). The two most common values for count
are 1 (wake a single
thread) and UINT32_MAX
(wake all threads).FUTEX_WAIT
/ futex_wait()
: wait on the futex, but only if the current
value of the futex integer matches the specified value
. The value
comparison and blocking is done atomically: if another thread changes the
value before the calling thread starts waiting, the calling thread will not
begin waiting at all, and the futex_wait()
call will return EAGAIN
immediately. A waiting thread may wake up spuriously, without a matching call
to futex_wake()
.FUTEX_WAKE_BITSET
: like FUTEX_WAKE
, but only consider waiting threads
that have specified a matching bitset (passed in value3
). Two bitsets match
if their bitwise and is non-zero. A thread that has not specified a bitset
is treated as having a bitset with all bits set (FUTEX_BITSET_MATCH_ANY
,
equal to 0xffffffff
).FUTEX_WAIT_BITSET
: like FUTEX_WAIT
, but the thread will only get woken by
wake operations specifying a matching bitset.FUTEX_REQUEUE
: wake up to value
threads waiting on the futex, and requeue
up to value2
(passed instead of the timeout
argument) of the remaining
waiting threads to wait on another futex specified by userspace_address2
,
without waking them up. Waking and requeueing threads is done atomically.Requeueing threads without waking them up is useful to avoid "thundering herd" issues with synchronization primitives like condition variables, where multiple threads may wait for an event, but an event can only be handled by a single thread at a time.
FUTEX_CMP_REQUEUE
: like FUTEX_REQUEUE
, but only if the current value of
the futex integer matches the specified value3
. The value comparison,
waking and requeueing threads are all done atomically.FUTEX_WAKE_OP
: modify the value of the futex specified by
userspace_address2
, wake up to value
threads waiting on the futex, and
optionally up to value2
(passed instead of the timeout
argument) threads
waiting on the futex specified by userspace_address2
.The details of this operation are not currently documented here, see the implementation for details.
Additionally, the FUTEX_PRIVATE_FLAG
flag can be or'ed in with one of the
operation values listed above. This flag restricts the call to only work on
other threads of the same process (as opposed to any threads in the system that
may have the same memory page mapped into their address space, possibly at a
different address), which enables additional optimizations in the syscall
implementation. The inverse of this flag is exposed as the process_shared
argument in futex_wait()
and futex_wake()
wrapper functions.
FUTEX_WAKE
, FUTEX_WAKE_BITSET
, FUTEX_WAKE_OP
: the number of the waiting
threads that have been woken up, which may be 0 or a positive number.FUTEX_WAIT
, FUTEX_WAIT_BITSET
: 0 if blocked and got woken up by an
explicit wake call or woke up spuriously, an error otherwise.FUTEX_REQUEUE
, FUTEX_CMP_REQUEUE
: the total number of threads woken up
and requeued.EAGAIN
: for wait operations, did not begin waiting, because the futex value
has already been changed.ETIMEDOUT
: for wait operations with a timeout, timed out.EFAULT
: the specified futex address is invalid.ENOSYS
: FUTEX_CLOCK_REALTIME
was specified, but the operation is not
FUTEX_WAIT
or FUTEX_WAIT_BITSET
.EINVAL
: The arithmetic-logical operation for FUTEX_WAKE_OP
is invalid.The following program demonstrates how futexes can be used to implement a simple "event" synchronization primitive. An event has a boolean state: it can be set or unset; the initial state being unset. The two operations on an event are waiting until it is set, and setting it (which wakes up any threads that were waiting for the event to get set).
Such a synchronization primitive could be used, for example, to notify threads that are waiting for another thread to perform some sort of complex initialization.
The implementation features two fast paths: both setting an event that no thread is waiting on, and trying to wait on an event that has already been set, are performed entirely in userspace without calling into the kernel. For this to work, the value of the futex integer is used to track both the state of the event (whether it has been set) and whether any threads are waiting on it.
#include <AK/Atomic.h>
#include <serenity.h>
class Event {
private:
enum State : u32 {
UnsetNoWaiters,
UnsetWithWaiters,
Set,
};
AK::Atomic<State> m_state { UnsetNoWaiters };
u32* state_futex_ptr() { return reinterpret_cast<u32*>(const_cast<State*>(m_state.ptr())); }
public:
void set()
{
State previous_state = m_state.exchange(Set, AK::memory_order_release);
// If there was anyone waiting, wake them all up.
// Fast path: no one was waiting, so we're done.
if (previous_state == UnsetWithWaiters)
futex_wake(state_futex_ptr(), UINT32_MAX, false);
}
void wait()
{
// If the state is UnsetNoWaiters, set it to UnsetWithWaiters.
State expected_state = UnsetNoWaiters;
bool have_exchanged = m_state.compare_exchange_strong(
expected_state, UnsetWithWaiters,
AK::memory_order_acquire);
if (have_exchanged)
expected_state = UnsetWithWaiters;
// We need to check the state in a loop and not just once
// because of the possibility of spurious wakeups.
// Fast path: if the state was already Set, we're done.
while (expected_state != Set) {
futex_wait(state_futex_ptr(), expected_state, nullptr, 0, false);
expected_state = m_state.load(AK::memory_order_acquire);
}
}
};
The name "futex" stands for "fast userspace mutex".
The futex()
system call originally appeared in Linux. Since then, many other
kernels implemented support for futex-like operations, under various names, in
particular:
ulock_wait()
and ulock_wake()
API;WaitOnAddress()
, WakeByAddressSingle()
and
WakeByAddressAll()
;umtx
;futex()
;gsync_wait()
, gsync_wake()
, and gsync_requeue()
.