Get a mutex type
#include <pthread.h>
int pthread_mutexattr_gettype(
const pthread_mutexattr_t * attr,
int * type );
- 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.
libc
Use the -l c option to
qcc
to link against this library.
This library is usually included automatically.
The pthread_mutexattr_gettype() function gets the mutex type attribute in the type parameter.
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.
Zero, and the value of the type attribute of attr is stored
in the object referenced by the type parameter; otherwise, an error.
- EINVAL
- Invalid value specified by attr.
POSIX 1003.1 XSI
Safety: | |
Cancellation point |
No |
Interrupt handler |
No |
Signal handler |
Yes |
Thread |
Yes |
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.
pthread_cond_timedwait(),
pthread_cond_wait(),
pthread_mutexattr_settype()