CODEWITHSUNDEEP
pthreadsmutex
jww
jww

Reputation: 102346

Are PTHREAD_MUTEX_* and PTHREAD_MUTEX_ERRORCHECK mutually exclusive?

The Open Group has a specification for pthread_mutex_lock, pthread_mutex_trylock, pthread_mutex_unlock and friends located here.

The page lists four mutex attribute values: PTHREAD_MUTEX_NORMAL, PTHREAD_MUTEX_ERRORCHECK, PTHREAD_MUTEX_RECURSIVE, and PTHREAD_MUTEX_DEFAULT.

Are all the values mutually exclusive? In a Debug configuration, are we allowed to OR those values together? For example, I'd like full error checking in Debug, so is PTHREAD_MUTEX_ERRORCHECK | PTHREAD_MUTEX_RECURSIVE a valid configuration?

The reason I ask is I'm catching an error pthread_mutexattr_settype. I'm not sure if its a valid configuration and an OS X implementation bug; or if its an invalid configuration and expected standard behavior. If its an OS X bug, I can still enjoy the enhanced error checking in debug configurations on other platforms.

Upvotes: 2

Views: 2399

Answers (1)

caf
caf

Reputation: 239181

A mutex can be of only one "type". You cannot combine them.

It doesn't really make sense to do so, anyway - PTHREAD_MUTEX_ERRORCHECK mutexes always return an error if you try to relock a mutex already locked by the same thread, whereas PTHREAD_MUTEX_RECURSIVE mutexes always succeed in that case. In the other error-checking cases (unlocking a mutex which another thread has locked, and unlocking an unlocked mutex) both PTHREAD_MUTEX_ERRORCHECK and PTHREAD_MUTEX_RECURSIVE have the same behaviour (always returning an error).

This means that your PTHREAD_MUTEX_RECURSIVE mutexes should remain the same type in "debug" builds, but it might make sense to substitute PTHREAD_MUTEX_ERRORCHECK for PTHREAD_MUTEX_DEFAULT and PTHREAD_MUTEX_NORMAL mutexes.

Upvotes: 3

Related Questions