Pthread Mutex: pthread_mutex_unlock() consumes lots of time

Question

I wrote a multi-thread program with pthread, using the producer-consumer model.

When I use Intel VTune profiler to profile my program, I found the producer and consumer spend lots of time on pthread_mutex_unlock. I don't understand why this happened. I think threads may wait a long time before they can acquire a mutex, but releasing a mutex should be fast, right?

The snapshot below is from Intel VTune. It shows the codes where consumer tries to fetch an item from the buffer, and time consumed by each code line.

My question is that why pthread_mutex_unlock has such overhead? Is the problem with pthread mutex itself or with the way I use it?

Answer 1

The pthread_mutex_unlock() function shall release the mutex object referenced by mutex. But, the manner in which a mutex is released is dependent upon the mutex's type attribute. If there are threads blocked on the mutex object referenced by mutex when pthread_mutex_unlock() is called, resulting in the mutex becoming available, the scheduling policy shall determine which thread shall acquire the mutex.

If the mutex type is PTHREAD_MUTEX_NORMAL, deadlock detection shall not be provided. Attempting to relock the mutex causes deadlock. If a thread attempts to unlock a mutex that it has not locked or a mutex which is unlocked, undefined behavior results.

If the mutex type is PTHREAD_MUTEX_ERRORCHECK, then error checking shall be provided. If a thread attempts to relock a mutex that it has already locked, an error shall be returned. If a thread attempts to unlock a mutex that it has not locked or a mutex which is unlocked, an error shall be returned.

If the mutex type is PTHREAD_MUTEX_RECURSIVE, then the mutex shall maintain the concept of a lock count. When a thread successfully acquires a mutex for the first time, the lock count shall be set to one. Every time a thread relocks this mutex, the lock count shall be incremented by one. Each time the thread unlocks the mutex, the lock count shall be decremented by one. When the lock count reaches zero, the mutex shall become available for other threads to acquire. If a thread attempts to unlock a mutex that it has not locked or a mutex which is unlocked, an error shall be returned.

If the mutex type is PTHREAD_MUTEX_DEFAULT, attempting to recursively lock the mutex results in undefined behavior. Attempting to unlock the mutex if it was not locked by the calling thread results in undefined behavior. Attempting to unlock the mutex if it is not locked results in undefined behavior.

I usually prefer to use PTHREAD_MUTEX_RECURSIVE mutexes, because in this case the mutex shall become available when the count reaches zero and the calling thread no longer has any locks on this mutex.