So guys, now, next obvious question that arises is how mutexes work.
So the only goal of the mutex is to grant access to critical section to only one and only one thread
of the process at a time.
This is the sole purpose of using mutexes.
Right?
So Posix, APR or Posix standard provides a data type p thread mutex using which we can declare and
define the mutex type objects.
Right?
So remember, it's a P thread T, it's a data type which is provided by Posix standards.
Now consider a short program here which is represented by this function foo.
And let us suppose that we have three concurrent threads, thread, T1 thread, T2 and T3.
All these threads are executing concurrently inside a function foo.
Now you can see that in the function foo.
We have a critical section now without deploying any thread synchronization protection on the thread,
T1 thread, T2 and T3 would going to execute inside this critical section in a concurrent manner.
And we have already seen an example where the concurrent access of threads inside a critical section
leads to several problems.
So here what we are looking is to use this mutex object to provide mutual exclusivity to each of these
threads t1, t2, T3 in relation to executing inside this critical section.
Our end goal is that that only one thread at a time execute inside this critical section.
Right.
This is our main goal.
So what we will going to do is that in order to provide mutual exclusivity of this critical section
to each of these threads, we will going to protect this critical section.
Or in other words, we will going to sandwich this critical section between the lock and unlock API
calls.
When we write p thread mutex lock, it simply means that whichever threads execute the instruction i1
would going to lock this mutex.
In other words, we say that that particular thread becomes the owner of this mutex.
Right.
So let us suppose that among these three threads T1, T2 and T3, it happens to be thread T1 which executes
the instruction I1 first.
It means that it is the thread t1 which becomes the owner of this mutex object.
After locking the mutex, the thread T1 is now allowed to execute inside the critical section.
Right.
So whichever thread locks the mutex shall be able to enter into critical section.
If a thread tries to lock already locked mutex, then that particular thread is locked.
Now in this example, the thread T1 is already executing in the critical section and the thread T1 has
already locked the mutex object, so it simply means that if the thread T2 and T3 tries to execute the
instruction i1 that is, if the thread T2 and T3 tries to lock the same mutex object, then those threads
would going to get blocked.
So it simply means that here thread t2 and thread thread t3 would going to get into the blocked state.
So you can see here that multiple threads may be blocked by the same mutex, as simple as that.
Here you have only one mutex, but this mutex is able to block the thread t2 and thread T3.
Next point says that when the thread exits out the critical section, it must unlock the mutex that
it had locked.
So you can see that when the thread T1 is finished with executing in the critical section, the thread
T1 must unlock the mutex which it had locked earlier.
Right.
So it simply means that when the thread T1 exits out the critical section, the mutex object would going
to be unlocked and we say that the mutex is now available.
Now going further among many threads, waiting for the same mutex, in our example we have thread T2
and T3 which were blocked by the mutex.
Right.
So among many threads which were waiting for the same mutex, mutex shall be granted to only one depending
on several factors such as thread, priority or operating system scheduling policy, etcetera.
Right.
So in this example thread, T2 and T3 were blocked by the mutex, but now since the mutex has become
available because the thread T1 has released the mutex, so either the mutex will be granted to thread
T2 or it would be granted to thread T3.
Right.
We can't say which thread it will be, but we can say that only one out of these two threads would go
in to lock the mutex.
Right.
So let us suppose that it is thread t2 which has been granted a lock to the mutex.
So now it's time for the thread t2 to execute in the critical section.
Right.
While thread T3 stays blocked.
Similarly, when the thread T2 leaves the critical section it will unlock the mutex object and now the
mutex will be granted to the thread t3 which is still in the blocked state.
Right.
So this is how the mutex locking and unlocking is done by several threads when several threads compete
for the same mutex.
Now discussing the next point thread must not intentionally die when holding the mutex lock that mutex
become unusable for forever.
So in this example we discussed that thread.
T1 was granted the mutex and the thread T1 entered into the critical section.
Right.
Now let us suppose that while executing the instruction i2 the thread t1 invokes p thread exit call.
So it simply means that thread one has been terminated, but thread one did not unlock the mutex.
It simply means that thread, T2 and T3 were going to stay blocked for forever.
Right?
In other words, thread 32 and thread T3 has entered into a deadlock situation.
They are waiting to grant a lock on the mutex which is logged by a thread which do not exist.
Right.
There is no one to release a lock on this mutex and hence the thread t2 and threat T3 would go into
stay blocked for forever.
So always remember that whenever you terminate a thread you must ensure that thread T1 must not hold
any mutex in the locked state.
Use of mutexes cause threads to block and unblock more the blocking and unblocking of threads, more
scheduling work overhead on operating system and hence poorer shall be the application performance.
And the next point say is that bigger the size of the critical section.
Here we have taken the critical section which is represented by instruction I two.
But this critical section could be hundreds of or thousands of lines of code, right?
So bigger the size of the critical section, larger the time the blocked threads would have to wait.
Right.
Because larger the size of the critical section means larger will be the time taken by the thread to
finish executing that critical section.
Right.
And it would lead to poorer performance of the application as well.
Right.
How would you feel if you have to go from the point A to the point B?
But in between these two points, there are many red traffic lights.
Right?
You will feel bad.
And of course it will going to take you more time to go from point A to point B.
The same applies here, right?
If multiple threads of the same process keeps on blocking and unblocking with a very high frequency,
then the threads of the application would span more time in only getting blocked and unblocked rather
than actually executing the application logic.
Right.
More the blocking and unblocking of threads in your application poorer shall be the performance of the
application as simple as that.
So now in the next lecture video we will going to discuss more APIs to work with mutexes and then we
will see how to make use of Mutexes in our actual programs.