Manual Pages  — _UMTX_OP

_umtx_op – interface for implementation of userspace threading synchronization primitives

LIBRARY SYNOPSIS DESCRIPTION STRUCTURES SLEEP QUEUES ROBUST UMUTEXES OPERATIONS RETURN VALUES ERRORS SEE ALSO STANDARDS BUGS

Standard C Library (libc, -lc)

#include <sys/types.h>

#include <sys/umtx.h>

int
_umtx_op(void *obj, int op, u_long val, void *uaddr, void *uaddr2);

The _umtx_op() system call provides kernel support for userspace implementation of the threading synchronization primitives. The 1:1 Threading Library (libthr, -lthr)uses the syscall to implement IEEE Std 1003.1-2001 ("POSIX.1") pthread locks, like mutexes, condition variables and so on.

The operations, performed by the _umtx_op() syscall, operate on userspace objects which are described by the following structures. Reserved fields and paddings are omitted. All objects require ABI-mandated alignment, but this is not currently enforced consistently on all architectures.

The following flags are defined for flag fields of all structures:

USYNC_PROCESS_SHARED
	Allow selection of the process-shared sleep queue for the thread sleep container, when the lock ownership cannot be granted immediately, and the operation must sleep. The process-shared or process-private sleep queue is selected based on the attributes of the memory mapping which contains the first byte of the structure, see mmap(2). Otherwise, if the flag is not specified, the process-private sleep queue is selected regardless of the memory mapping attributes, as an optimization. See the SLEEP QUEUES subsection below for more details on sleep queues.

Mutex	struct umutex {         volatile lwpid_t m_owner;         uint32_t m_flags;         uint32_t m_ceilings[2];         uintptr_t m_rb_lnk; }; The m_owner field is the actual lock. It contains either the thread identifier of the lock owner in the locked state, or zero when the lock is unowned. The highest bit set indicates that there is contention on the lock. The constants are defined for special values:
UMUTEX_UNOWNED
	Zero, the value stored in the unowned lock.
UMUTEX_CONTESTED
	The contention indicator.
UMUTEX_RB_OWNERDEAD
	A thread owning the robust mutex terminated. The mutex is in unlocked state.
UMUTEX_RB_NOTRECOV
	The robust mutex is in a non-recoverable state. It cannot be locked until reinitialized.

The m_flags field may contain the following umutex-specific flags, in addition to the common flags:

UMUTEX_PRIO_INHERIT
	Mutex implements Priority Inheritance protocol.
UMUTEX_PRIO_PROTECT
	Mutex implements Priority Protection protocol.
UMUTEX_ROBUST
	Mutex is robust, as described in the ROBUST UMUTEXES section below.
UMUTEX_NONCONSISTENT
	Robust mutex is in a transient non-consistent state. Not used by kernel.

In the manual page, mutexes not having UMUTEX_PRIO_INHERIT and UMUTEX_PRIO_PROTECT flags set, are called normal mutexes. Each type of mutex (normal, priority-inherited, and priority-protected) has a separate sleep queue associated with the given key.

For priority protected mutexes, the m_ceilings array contains priority ceiling values. The m_ceilings[0] is the ceiling value for the mutex, as specified by IEEE Std 1003.1-2008 ("POSIX.1") for the Priority Protected mutex protocol. The m_ceilings[1] is used only for the unlock of a priority protected mutex, when unlock is done in an order other than the reversed lock order. In this case, m_ceilings[1] must contain the ceiling value for the last locked priority protected mutex, for proper priority reassignment. If, instead, the unlocking mutex was the last priority propagated mutex locked by the thread, m_ceilings[1] should contain -1. This is required because kernel does not maintain the ordered lock list.

Condition variable
	struct ucond {         volatile uint32_t c_has_waiters;         uint32_t c_flags;         uint32_t c_clockid; }; A non-zero c_has_waiters value indicates that there are in-kernel waiters for the condition, executing the UMTX_OP_CV_WAIT request. The c_flags field contains flags. Only the common flags ( USYNC_PROCESS_SHARED) are defined for ucond. The c_clockid member provides the clock identifier to use for timeout, when the UMTX_OP_CV_WAIT request has both the CVWAIT_CLOCKID flag and the timeout specified. Valid clock identifiers are a subset of those for clock_gettime(2): CLOCK_MONOTONIC CLOCK_MONOTONIC_FAST CLOCK_MONOTONIC_PRECISE CLOCK_PROF CLOCK_REALTIME CLOCK_REALTIME_FAST CLOCK_REALTIME_PRECISE CLOCK_SECOND CLOCK_UPTIME CLOCK_UPTIME_FAST CLOCK_UPTIME_PRECISE CLOCK_VIRTUAL
Reader/writer lock
	struct urwlock {         volatile int32_t rw_state;         uint32_t rw_flags;         uint32_t rw_blocked_readers;         uint32_t rw_blocked_writers; }; The rw_state field is the actual lock. It contains both the flags and counter of the read locks which were granted. Names of the rw_state bits are following:
URWLOCK_WRITE_OWNER
	Write lock was granted.
URWLOCK_WRITE_WAITERS
	There are write lock waiters.
URWLOCK_READ_WAITERS
	There are read lock waiters.
URWLOCK_READER_COUNT(c)
	Returns the count of currently granted read locks.

At any given time there may be only one thread to which the writer lock is granted on the struct rwlock, and no threads are granted read lock. Or, at the given time, up to URWLOCK_MAX_READERS threads may be granted the read lock simultaneously, but write lock is not granted to any thread.

The following flags for the rw_flags member of struct urwlock are defined, in addition to the common flags:

URWLOCK_PREFER_READER
	If specified, immediately grant read lock requests when urwlock is already read-locked, even in presence of unsatisfied write lock requests. By default, if there is a write lock waiter, further read requests are not granted, to prevent unfair write lock waiter starvation.

The rw_blocked_readers and rw_blocked_writers members contain the count of threads which are sleeping in kernel, waiting for the associated request type to be granted. The fields are used by kernel to update the URWLOCK_READ_WAITERS and URWLOCK_WRITE_WAITERS flags of the rw_state lock after requesting thread was woken up.

Semaphore
	struct _usem2 {         volatile uint32_t _count;         uint32_t _flags; }; The _count word represents a counting semaphore. A non-zero value indicates an unlocked (posted) semaphore, while zero represents the locked state. The maximal supported semaphore count is USEM_MAX_COUNT. The _count word, besides the counter of posts (unlocks), also contains the USEM_HAS_WAITERS bit, which indicates that locked semaphore has waiting threads. The USEM_COUNT() macro, applied to the _count word, returns the current semaphore counter, which is the number of posts issued on the semaphore. The following bits for the _flags member of struct _usem2 are defined, in addition to the common flags:
USEM_NAMED
	Flag is ignored by kernel.

Timeout parameter
	struct _umtx_time {         struct timespec _timeout;         uint32_t _flags;         uint32_t _clockid; }; Several _umtx_op() operations allow the blocking time to be limited, failing the request if it cannot be satisfied in the specified time period. The timeout is specified by passing either the address of struct timespec, or its extended variant, struct _umtx_time, as the uaddr2 argument of _umtx_op(). They are distinguished by the uaddr value, which must be equal to the size of the structure pointed to by uaddr2, casted to uintptr_t. The _timeout member specifies the time when the timeout should occur. Legal values for clock identifier _clockid are shared with the clock_id argument to the clock_gettime(2) function, and use the same underlying clocks. The specified clock is used to obtain the current time value. Interval counting is always performed by the monotonic wall clock. The _flags argument allows the following flags to further define the timeout behaviour:
UMTX_ABSTIME
	The _timeout value is the absolute time. The thread will be unblocked and the request failed when specified clock value is equal or exceeds the _timeout. If the flag is absent, the timeout value is relative, that is the amount of time, measured by the monotonic wall clock from the moment of the request start.

When a locking request cannot be immediately satisfied, the thread is typically put to sleep, which is a non-runnable state terminated by the wake operation. Lock operations include a try variant which returns an error rather than sleeping if the lock cannot be obtained. Also, _umtx_op() provides requests which explicitly put the thread to sleep.

Wakes need to know which threads to make runnable, so sleeping threads are grouped into containers called sleep queues. A sleep queue is identified by a key, which for _umtx_op() is defined as the physical address of some variable. Note that the physical address is used, which means that same variable mapped multiple times will give one key value. This mechanism enables the construction of process-shared locks.

A related attribute of the key is shareability. Some requests always interpret keys as private for the current process, creating sleep queues with the scope of the current process even if the memory is shared. Others either select the shareability automatically from the mapping attributes, or take additional input as the USYNC_PROCESS_SHARED common flag. This is done as optimization, allowing the lock scope to be limited regardless of the kind of backing memory.

Only the address of the start byte of the variable specified as key is important for determining corresponding sleep queue. The size of the variable does not matter, so, for example, sleep on the same address interpeted as uint32_t and long on a little-endian 64-bit platform would collide.

The last attribute of the key is the object type. The sleep queue to which a sleeping thread is assigned is an individual one for simple wait requests, mutexes, rwlocks, condvars and other primitives, even when the physical address of the key is same.

When waking up a limited number of threads from a given sleep queue, the highest priority threads that have been blocked for the longest on the queue are selected.

The robust umutexes are provided as a substrate for a userspace library to implement POSIX robust mutexes. A robust umutex must have the UMUTEX_ROBUST flag set.

On thread termination, the kernel walks two lists of mutexes. The two lists head addresses must be provided by a prior call to UMTX_OP_ROBUST_LISTS request. The lists are singly-linked. The link to next element is provided by the m_rb_lnk member of the struct umutex.

Robust list processing is aborted if the kernel finds a mutex with any of the following conditions:

	the UMUTEX_ROBUST flag is not set
	not owned by the current thread, except when the mutex is pointed to by the robust_inactive member of the struct umtx_robust_lists_params, registered for the current thread
	the combination of mutex flags is invalid
	read of the umutex memory faults
	the list length limit described in libthr(3) is reached.

Every mutex in both lists is unlocked as if the UMTX_OP_MUTEX_UNLOCK request is performed on it, but instead of the UMUTEX_UNOWNED value, the m_owner field is written with the UMUTEX_RB_OWNERDEAD value. When a mutex in the UMUTEX_RB_OWNERDEAD state is locked by kernel due to the UMTX_OP_MUTEX_TRYLOCK and UMTX_OP_MUTEX_LOCK requests, the lock is granted and EOWNERDEAD error is returned.

Also, the kernel handles the UMUTEX_RB_NOTRECOV value of the m_owner field specially, always returning the ENOTRECOVERABLE error for lock attempts, without granting the lock.

If successful, all requests, except UMTX_SHM_CREAT and UMTX_SHM_LOOKUP sub-requests of the UMTX_OP_SHM request, will return zero. The UMTX_SHM_CREAT and UMTX_SHM_LOOKUP return a shared memory file descriptor on success. On error -1 is returned, and the errno variable is set to indicate the error.

The _umtx_op() operations can fail with the following errors:

[EFAULT]	One of the arguments point to invalid memory.
[EINVAL]	The clock identifier, specified for the struct _umtx_time timeout parameter, or in the c_clockid member of struct ucond, is invalid.
[EINVAL]	The type of the mutex, encoded by the m_flags member of struct umutex, is invalid.
[EINVAL]	The m_owner member of the struct umutex has changed the lock owner thread identifier during unlock.
[EINVAL]	The timeout.tv_sec or timeout.tv_nsec member of struct _umtx_time is less than zero, or timeout.tv_nsec is greater than 1000000000.
[EINVAL]	The op argument specifies invalid operation.
[EINVAL]	The uaddr argument for the UMTX_OP_SHM request specifies invalid operation.
[EINVAL]	The UMTX_OP_SET_CEILING request specifies non priority protected mutex.
[EINVAL]	The new ceiling value for the UMTX_OP_SET_CEILING request, or one or more of the values read from the m_ceilings array during lock or unlock operations, is greater than RTP_PRIO_MAX.
[EPERM]	Unlock attempted on an object not owned by the current thread.
[EOWNERDEAD]
	The lock was requested on an umutex where the m_owner field was set to the UMUTEX_RB_OWNERDEAD value, indicating terminated robust mutex. The lock was granted to the caller, so this error in fact indicates success with additional conditions.
[ENOTRECOVERABLE]
	The lock was requested on an umutex which m_owner field is equal to the UMUTEX_RB_NOTRECOV value, indicating abandoned robust mutex after termination. The lock was not granted to the caller.
[ENOTTY]	The shared memory object, associated with the address passed to the UMTX_SHM_ALIVE sub-request of UMTX_OP_SHM request, was destroyed.
[ESRCH]	For the UMTX_SHM_LOOKUP, UMTX_SHM_DESTROY, and UMTX_SHM_ALIVE sub-requests of the UMTX_OP_SHM request, there is no shared memory object associated with the provided key.
[ENOMEM]	The UMTX_SHM_CREAT sub-request of the UMTX_OP_SHM request cannot be satisfied, because allocation of the shared memory object would exceed the RLIMIT_UMTXP resource limit, see setrlimit(2).
[EAGAIN]	The maximum number of readers ( URWLOCK_MAX_READERS) were already granted ownership of the given struct rwlock for read.
[EBUSY]	A try mutex lock operation was not able to obtain the lock.
[ETIMEDOUT]
	The request specified a timeout in the uaddr and uaddr2 arguments, and timed out before obtaining the lock or being woken up.
[EINTR]	A signal was delivered during wait, for a non-restartable operation. Operations with timeouts are typically non-restartable, but timeouts specified in absolute time may be restartable.
[ERESTART]	A signal was delivered during wait, for a restartable operation. Mutex lock requests without timeout specified are restartable. The error is not returned to userspace code since restart is handled by usual adjustment of the instruction counter.

A window between a unlocking robust mutex and resetting the pointer in the robust_inact_offset member of the registered struct umtx_robust_lists_params allows another thread to destroy the mutex, thus making the kernel inspect freed or reused memory. The libthr implementation is only vulnerable to this race when operating on a shared mutex. A possible fix for the current implementation is to strengthen the checks for shared mutexes before terminating them, in particular, verifying that the mutex memory is mapped from a shared memory object allocated by the UMTX_OP_SHM request. This is not done because it is believed that the race is adequately covered by other consistency checks, while adding the check would prevent alternative implementations of libpthread.