pthread_mutexattr_gettype()

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.
EINVAL
Invalid mutex attribute object attr.

Classification:

POSIX 1003.1 XSI

Safety:  
Cancellation point No
Interrupt handler 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.

Last modified: 2013-12-23

comments powered by Disqus