A mutex is a MUTual EXclusion object, and is useful for protecting shared data structures from concurrent modifications, and implementing critical sections and monitors.
A mutex has two possible states: unlocked (not owned by any task), and locked (owned by one task). A mutex can never be owned by two different tasks simultaneously. A task attempting to lock a mutex that is already locked by another task is blocked until the latter unlocks the mutex first.
Xenomai mutex services enforce a priority inheritance protocol in order to solve priority inversions.
Files | |
file | mutex.c |
This file is part of the Xenomai project. | |
Functions | |
int | rt_mutex_create (RT_MUTEX *mutex, const char *name) |
Create a mutex. | |
int | rt_mutex_delete (RT_MUTEX *mutex) |
Delete a mutex. | |
int | rt_mutex_acquire (RT_MUTEX *mutex, RTIME timeout) |
Acquire a mutex. | |
int | rt_mutex_release (RT_MUTEX *mutex) |
Unlock mutex. | |
int | rt_mutex_inquire (RT_MUTEX *mutex, RT_MUTEX_INFO *info) |
Inquire about a mutex. | |
int | rt_mutex_bind (RT_MUTEX *mutex, const char *name, RTIME timeout) |
Bind to a mutex. | |
static int | rt_mutex_unbind (RT_MUTEX *mutex) |
Unbind from a mutex. |
|
Acquire a mutex. Attempt to lock a mutex. The calling task is blocked until the mutex is available, in which case it is locked again before this service returns. Mutexes have an ownership property, which means that their current owner is tracked. Xenomai mutexes are implicitely recursive and implement the priority inheritance protocol. Since a nested locking count is maintained for the current owner, rt_mutex_lock() and rt_mutex_unlock() must be used in pairs. Tasks pend on mutexes by priority order.
Environments: This service can be called from:
Rescheduling: always unless the request is immediately satisfied or timeout specifies a non-blocking operation. If the caller is blocked, the current owner's priority might be temporarily raised as a consequence of the priority inheritance protocol.
|
|
Bind to a mutex. This user-space only service retrieves the uniform descriptor of a given Xenomai mutex identified by its symbolic name. If the mutex does not exist on entry, this service blocks the caller until a mutex of the given name is created.
Environments: This service can be called from:
Rescheduling: always unless the request is immediately satisfied or timeout specifies a non-blocking operation.
|
|
Create a mutex. Create a mutual exclusion object that allows multiple tasks to synchronize access to a shared resource. A mutex is left in an unlocked state after creation.
Environments: This service can be called from:
Rescheduling: possible. |
|
Delete a mutex. Destroy a mutex and release all the tasks currently pending on it. A mutex exists in the system since rt_mutex_create() has been called to create it, so this service must be called in order to destroy it afterwards.
Environments: This service can be called from:
Rescheduling: possible. |
|
Inquire about a mutex. Return various information about the status of a given mutex.
Environments: This service can be called from:
Rescheduling: never. |
|
Unlock mutex. Release a mutex. If the mutex is pended, the first waiting task (by priority order) is immediately unblocked and transfered the ownership of the mutex; otherwise, the mutex is left in an unlocked state.
Environments: This service can be called from:
Rescheduling: possible. |
|
Unbind from a mutex. This user-space only service unbinds the calling task from the mutex object previously retrieved by a call to rt_mutex_bind().
Rescheduling: never. |