Collaboration diagram for Mutex services.:

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. More...

int	rt_mutex_delete (RT_MUTEX *mutex)
	Delete a mutex. More...

int	rt_mutex_acquire (RT_MUTEX *mutex, RTIME timeout)
	Acquire a mutex. More...

int	rt_mutex_acquire_until (RT_MUTEX *mutex, RTIME timeout)
	Acquire a mutex (with absolute timeout date). More...

int	rt_mutex_release (RT_MUTEX *mutex)
	Unlock mutex. More...

int	rt_mutex_inquire (RT_MUTEX mutex, RT_MUTEX_INFO info)
	Inquire about a mutex. More...

int	rt_mutex_bind (RT_MUTEX mutex, const char name, RTIME timeout)
	Bind to a mutex. More...

static int	rt_mutex_unbind (RT_MUTEX *mutex)
	Unbind from a mutex. More...

Detailed Description

Mutex services.

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.

Function Documentation

int rt_mutex_acquire	(	RT_MUTEX *	mutex,
		RTIME	timeout
	)

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 implicitly recursive and implement the priority inheritance protocol.

Since a nested locking count is maintained for the current owner, rt_mutex_acquire{_until}() and rt_mutex_release() must be used in pairs.

Tasks pend on mutexes by priority order.

Parameters

mutex	The descriptor address of the mutex to acquire.
timeout	The number of clock ticks to wait for the mutex to be available to the calling task (see note). Passing TM_INFINITE causes the caller to block indefinitely until the mutex is available. Passing TM_NONBLOCK causes the service to return immediately without waiting if the mutex is still locked by another task.

Returns: 0 is returned upon success. Otherwise:

-EINVAL is returned if mutex is not a mutex descriptor.
-EIDRM is returned if mutex is a deleted mutex descriptor, including if the deletion occurred while the caller was sleeping on it.
-EWOULDBLOCK is returned if timeout is equal to TM_NONBLOCK and the mutex is not immediately available.
-EINTR is returned if rt_task_unblock() has been called for the waiting task before the mutex has become available.
-ETIMEDOUT is returned if the mutex cannot be made available to the calling task within the specified amount of time.
-EPERM is returned if this service was called from a context which cannot be given the ownership of the mutex (e.g. interrupt, non-realtime context).

Environments:

This service can be called from:

Kernel-based task
User-space task (switches to primary mode)

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.

Note: The timeout value will be interpreted as jiffies if the native skin is bound to a periodic time base (see CONFIG_XENO_OPT_NATIVE_PERIOD), or nanoseconds otherwise.

Examples:: mutex.c.

int rt_mutex_acquire_until	(	RT_MUTEX *	mutex,
		RTIME	timeout
	)

Acquire a mutex (with absolute timeout date).

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 implicitly recursive and implement the priority inheritance protocol.

Since a nested locking count is maintained for the current owner, rt_mutex_acquire{_until}() and rt_mutex_release() must be used in pairs.

Tasks pend on mutexes by priority order.

Parameters

mutex	The descriptor address of the mutex to acquire.
timeout	The absolute date specifying a time limit to wait for the mutex to be available to the calling task (see note).

Returns: 0 is returned upon success. Otherwise:

-EINVAL is returned if mutex is not a mutex descriptor.
-EIDRM is returned if mutex is a deleted mutex descriptor, including if the deletion occurred while the caller was sleeping on it.
-EWOULDBLOCK is returned if timeout is equal to TM_NONBLOCK and the mutex is not immediately available.
-EINTR is returned if rt_task_unblock() has been called for the waiting task before the mutex has become available.
-ETIMEDOUT is returned if the mutex cannot be made available to the calling task until the absolute timeout date is reached.
-EPERM is returned if this service was called from a context which cannot be given the ownership of the mutex (e.g. interrupt, non-realtime context).

Environments:

This service can be called from:

Kernel-based task
User-space task (switches to primary mode)

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.

Note: The timeout value will be interpreted as jiffies if the native skin is bound to a periodic time base (see CONFIG_XENO_OPT_NATIVE_PERIOD), or nanoseconds otherwise.

int rt_mutex_bind	(	RT_MUTEX *	mutex,
		const char *	name,
		RTIME	timeout
	)

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.

Parameters

name	A valid NULL-terminated name which identifies the mutex to bind to.
mutex	The address of a mutex descriptor retrieved by the operation. Contents of this memory is undefined upon failure.
timeout	The number of clock ticks to wait for the registration to occur (see note). Passing TM_INFINITE causes the caller to block indefinitely until the object is registered. Passing TM_NONBLOCK causes the service to return immediately without waiting if the object is not registered on entry.

Returns: 0 is returned upon success. Otherwise:

-EFAULT is returned if mutex or name is referencing invalid memory.
-EINTR is returned if rt_task_unblock() has been called for the waiting task before the retrieval has completed.
-EWOULDBLOCK is returned if timeout is equal to TM_NONBLOCK and the searched object is not registered on entry.
-ETIMEDOUT is returned if the object cannot be retrieved within the specified amount of time.
-EPERM is returned if this service should block, but was called from a context which cannot sleep (e.g. interrupt, non-realtime context).

Environments:

This service can be called from:

User-space task (switches to primary mode)

Rescheduling: always unless the request is immediately satisfied or timeout specifies a non-blocking operation.

Note: The timeout value will be interpreted as jiffies if the native skin is bound to a periodic time base (see CONFIG_XENO_OPT_NATIVE_PERIOD), or nanoseconds otherwise.

int rt_mutex_create	(	RT_MUTEX *	mutex,
		const char *	name
	)

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.

Parameters

mutex	The address of a mutex descriptor Xenomai will use to store the mutex-related data. This descriptor must always be valid while the mutex is active therefore it must be allocated in permanent memory.
name	An ASCII string standing for the symbolic name of the mutex. When non-NULL and non-empty, this string is copied to a safe place into the descriptor, and passed to the registry package if enabled for indexing the created mutex.

Returns: 0 is returned upon success. Otherwise:

-ENOMEM is returned if the system fails to get enough dynamic memory from the global real-time heap in order to register the mutex.
-EEXIST is returned if the name is already in use by some registered object.
-EPERM is returned if this service was called from an asynchronous context.

Environments:

This service can be called from:

Kernel module initialization/cleanup code
Kernel-based task
User-space task

Rescheduling: possible.

Examples:: mutex.c.

int rt_mutex_delete ( RT_MUTEX * mutex )

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.

Parameters

mutex The descriptor address of the affected mutex.

Returns: 0 is returned upon success. Otherwise:

-EINVAL is returned if mutex is not a mutex descriptor.
-EIDRM is returned if mutex is a deleted mutex descriptor.
-EPERM is returned if this service was called from an asynchronous context.

Environments:

This service can be called from:

Kernel module initialization/cleanup code
Kernel-based task
User-space task

Rescheduling: possible.

Examples:: mutex.c.

References xnheap_free(), xnpod_schedule(), and xnregistry_remove().

int rt_mutex_inquire	(	RT_MUTEX *	mutex,
		RT_MUTEX_INFO *	info
	)

Inquire about a mutex.

Return various information about the status of a given mutex.

Parameters

mutex	The descriptor address of the inquired mutex.
info	The address of a structure the mutex information will be written to.

Returns: 0 is returned and status information is written to the structure pointed at by info upon success. Otherwise:

-EINVAL is returned if mutex is not a mutex descriptor.
-EIDRM is returned if mutex is a deleted mutex descriptor.

Environments:

This service can be called from:

Kernel module initialization/cleanup code
Interrupt service routine
Kernel-based task
User-space task

Rescheduling: never.

References rt_mutex_info::locked, rt_mutex_info::name, rt_mutex_info::nwaiters, and rt_mutex_info::owner.

int rt_mutex_release ( RT_MUTEX * mutex )

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.

Parameters

mutex The descriptor address of the released mutex.

Returns: 0 is returned upon success. Otherwise:

-EINVAL is returned if mutex is not a mutex descriptor.
-EIDRM is returned if mutex is a deleted mutex descriptor.
-EPERM is returned if mutex is not owned by the current task, or more generally if this service was called from a context which cannot own any mutex (e.g. interrupt, or non-realtime context).

Environments:

This service can be called from:

Kernel-based task
User-space task (switches to primary mode)

Rescheduling: possible.

Examples:: mutex.c.

References xnpod_schedule(), and xnsynch_release().

int rt_mutex_unbind ( RT_MUTEX * mutex )

inlinestatic

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().

Parameters

mutex The address of a mutex descriptor to unbind from.

Returns: 0 is always returned.

This service can be called from:

User-space task.

Rescheduling: never.

Files

Functions

Detailed Description

Function Documentation