Ubuntu Manpages

FUTEX_TRYLOCK_PI

try to lock a priority-inheritance futex

Standard C library (libc, -lc)

#include <linux/futex.h>  /* Definition of FUTEX_* constants */
#include <sys/syscall.h>  /* Definition of SYS_* constants */
#include <unistd.h>
long syscall(SYS_futex, uint32_t *uaddr, FUTEX_TRYLOCK_PI);

This operation tries to acquire the lock at uaddr. It is invoked when a user-space atomic acquire did not succeed because the futex word was not 0.

Because the kernel has access to more state information than user space, acquisition of the lock might succeed if performed by the kernel in cases where the futex word (i.e., the state information accessible to use-space) contains stale state (FUTEX_WAITERS and/or FUTEX_OWNER_DIED). This can happen when the owner of the futex died. User space cannot handle this condition in a race-free manner, but the kernel can fix this up and acquire the futex.

On error, -1 is returned, and errno is set to indicate the error.

On success, FUTEX_TRYLOCK_PI Returns 0 if the futex was successfully locked.

See futex(2).

The futex owner thread ID of uaddr is about to exit, but has not yet handled the internal state cleanup. Try again.
The futex word at uaddr is already locked by the caller.
The kernel detected an inconsistency between the user-space state at uaddr and the kernel state. This indicates either state corruption or that the kernel found a waiter on uaddr which is waiting via FUTEX_WAIT(2const) or FUTEX_WAIT_BITSET(2const).
The kernel could not allocate memory to hold state information.
A run-time check determined that the operation is not available. The PI-futex operations are not implemented on all architectures and are not supported on some CPU variants.
The caller is not allowed to attach itself to the futex at uaddr. (This may be caused by a state corruption in user space.)
The thread ID in the futex word at uaddr does not exist.

Linux.

Linux 2.6.18.

futex(2)