In effect, if you would like to thoroughly test and debug your application and don't really care about performance (right now, at least), then set up your mutex as follows:

• Set the robust attribute on it (allowing one to catch the owner-dies-without-unlocking case): pthread_mutexattr_setrobust(&attr, PTHREAD_MUTEX_ROBUST)
• Set the type to error checking (allowing one to catch the self-deadlock / relock case):
  pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_ERRORCHECK)
  

On the other hand, a well-designed and proven application that requires you to squeeze out performance would use the normal (default) mutex type and attributes. The preceding cases will not be caught (and will instead result in undefined behavior), but then, they should never occur!

If one requires a recursive lock, (obviously) set the mutex type to PTHREAD_MUTEX_RECURSIVE. With the recursive mutex, it's important to realize that if the mutex lock is performed n times, it must also be unlocked n times in order for it be considered to be truly in the unlocked state (and therefore lockable again).

In a multiprocess and multithreaded application, if there is a need to use a mutex lock between threads of different processes, this can be achieved via the process-shared attribute of the mutex object. Note that, in this case, the memory that contains the mutex must itself be shared between the processes (we usually use a shared memory segment).

The PI and the priority ceiling attributes allow the developer to safeguard the application against a well-understood software risk: priority inversion.