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 owning task unlocks the mutex first.
Files | |
file | mutex.c |
This file is part of the RTAI 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_lock (RT_MUTEX *mutex) |
Acquire a mutex. | |
int | rt_mutex_unlock (RT_MUTEX *mutex) |
Unlock mutex. | |
int | rt_mutex_inquire (RT_MUTEX *mutex, RT_MUTEX_INFO *info) |
Inquire about a mutex. |
|
Create a mutex. Create a mutual exclusion object that allows multiple threads to synchronize access to a shared resource. A mutex is left in an unlocked state after creation.
Context: This routine can be called on behalf of a task or from the initialization code. |
|
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.
Side-effect: This routine calls the rescheduling procedure if tasks have been woken up as a result of the deletion. Context: This routine can always be called on behalf of a task, or from the initialization code. |
|
Inquire about a mutex. Return various information about the status of a given mutex.
Context: This routine can be called on behalf of a task, interrupt context or from the initialization code. |
|
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. RTAI 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.
Side-effect: This routine calls the rescheduling procedure unless the mutex is immediately available. If the caller is blocked, the current owner priority might be temporarily raised as a consequence of the priority inheritance protocol. Context: This routine must be called on behalf of a task. |
|
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.
Side-effect: This routine calls the rescheduling procedure if a task is woken up as a result of the operation. Context: This routine can be called on behalf of a task or from the initialization code. |