When you have a multi-threaded application, the different threads sometimes share a common resource, such as a global variable, Files or similar. This shared source often cannot be accessed at the same time, so a construct is needed to ensure that only one thread is using that resource at a time.
To make sure that this common resources are use by one thread at a time, thread library provide a MUTual EXclusive flag, Mutex.
Lock Mutex ...
Common Resource/Critical Section
Unlock Mutex ...Mutex acts as a gate keeper to a section of code, contain common resource, allowing one thread in and blocking access to all other thread. This ensures that the code being controled will only be hit by a single thread at a time.
Thread library provides below function which is associated with mutex.
pthread_mutexattr_init : To initialize mutex attributes object
pthread_mutexattr_destroy: To destroy mutex attributes objectMutex attributes are protocol, pshared, prioceiling, robustness & types of mutex. As mutex attribute object is opaque type, appropriate set and get functions are availables to manupulate mutex attributes.pthread_mutex_init : To initialize mutex
pthread_mutex_destroy : To destroy mutex
pthread_mutex_lock : To lock mutex
pthread_mutex_trylock : To lock mutex
pthread_mutex_unlock : To unlock mutex
Linux provide three types of mutex, which have different application from one another.
Note : Mutex in example mutex_type_normal.c, mutex_type_errorcheck.c, mutex_type_recursive.c are containting default attribute except type. Default attributes are as follows:
protocol : PTHREAD_PRIO_NONE
pshared : PTHREAD_PROCESS_PRIVATE
prioceiling : 0
robustness : PTHREAD_MUTEX_STALLED
Normal Mutex
When you don’t mention any type while creating mutex, mutex created with normal type(default). Below is the example of behaviour of normal thread.
When thread-1 aquire mutex lock, thread-2 stops its execution till thread-1 unlock it. Once thread-1 unlock(release) the mutex lock, thread-2 aquire lock and start executing code of thread-2.
A normal mutex usually does not record or check thread ownership. Change above code with following line and run the program. You’ll observer that thread-1 and thread-2 running parallal. This is because mutex locked by one thread can unlock by another thread.
START_THREAD(thread_num);pthread_mutex_unlock(&mutex); // Add this line
pthread_mutex_lock(&mutex);
printf(IN_THREAD " Thread %d acquire lock \n", thread_num);
Error Checking Mutex
An Errorcheck mutex is locked exactly once by a thread, like a normal mutex. If a thread tries to lock the mutex again without first unlocking it, the thread receives an error. If a thread other than the owner tries to unlock an errorcheck mutex, an error is returned. Thus, errorcheck mutexes are more informative than normal mutexes. Errorcheck mutexes are useful during development and debugging. Errorcheck mutexes can be replaced with normal mutexes when the code is put into production use, or left to provide the additional checking.
Note : Errorcheck mutexes may be slower than normal mutexes, because they do more internal tracking. The debugger can always display the current owner (if any) of an errorcheck mutex.
Execute above program with mutex type PTHREAD_MUTEX_NORMAL, you’ll observe your program stuck while locking mutex second time.
Execute above program with mutex type PTHREAD_MUTEX_ERRORCHECK and observe the output. You’ll notice thread was not stuck in deadlock, instead, it returns error EDEADLK indicate “A deadlock condition was detected”.
Once mutex was unlocked(released), if you try unlocking again you’ll get error of EPERM indicates “Current thread doesn’t own mutex”.
Recursive Mutex
A recursive mutex can be locked more than once by a given thread without causing a deadlock. When a thread first successfully locks a recursive mutex, it owns that mutex and the lock count is set to 1. Any other thread attempting to lock the mutex blocks until the mutex becomes unlocked. If the owner of the mutex attempts to lock the mutex again, the lock count is incremented, and the thread continues running. When an owner unlocks a recursive mutex, the lock count is decremented. The mutex remains locked and owned until the count reaches zero. Remember, the thread must call the pthread_mutex_unlock() routine the same number of times that it called the pthread_mutex_lock() routine before another thread can lock the mutex.
