pthread_mutexattr_gettype()
QNX SDP8.0C Library ReferenceAPIDeveloper
Get a mutex type
Synopsis:
#include <pthread.h>
int pthread_mutexattr_gettype(
const pthread_mutexattr_t * attr,
int * type );
Arguments:
- attr
- A pointer to the pthread_mutexattr_t object that you want to get the attribute from.
- type
- A pointer to a location where the function can store the type.
Library:
libc
Use the -l c option to qcc to link against this library. This library is usually included automatically.
Description:
The pthread_mutexattr_gettype() function gets the mutex type from the mutex attribute object attr and stores it in type. Valid mutex types include:
- PTHREAD_MUTEX_NORMAL
- No deadlock detection. A thread that attempts to relock this mutex without first unlocking it deadlocks. Attempts to unlock a mutex locked by a different thread or attempts to unlock an unlocked mutex result in undefined behavior.
- PTHREAD_MUTEX_ERRORCHECK
- Provides error checking.
A thread returns with an error when it attempts to:
- Relock this mutex without first unlocking it.
- Unlock a mutex that another thread has locked.
- Unlock an unlocked mutex.
- PTHREAD_MUTEX_RECURSIVE
- A thread that attempts to relock this mutex without first unlocking it succeeds in locking the mutex. The relocking deadlock that can occur with mutexes of type PTHREAD_MUTEX_NORMAL can't occur with this mutex type. Multiple locks of this mutex require the same number of unlocks to release the mutex before another thread can acquire the mutex. A thread that attempts to unlock a mutex that another thread has locked, or unlock an unlocked mutex, returns with an error.
- PTHREAD_MUTEX_DEFAULT
- The default value of the type attribute. Attempts to recursively lock a mutex of this type, or unlock a mutex of this type that isn't locked by the calling thread, or unlock a mutex of this type that isn't locked, results in undefined behavior.
Returns:
- EOK
- Success.
Classification:
Safety: | |
---|---|
Cancellation point | No |
Signal handler | Yes |
Thread | Yes |
Caveats:
An application shouldn't use a PTHREAD_MUTEX_RECURSIVE mutex with condition variables because the implicit unlock performed for a pthread_cond_wait() or pthread_cond_timedwait() may not actually release the mutex (if it's been locked multiple times). If this happens, no other thread can satisfy the condition of the predicate.
Page updated: