In my previous article Issues with Multithreaded Programming : Part 1 I have explained about two most common issues of Multithreading programming 1) Race Condition and 2) DeadLock. Continuing to my previous article, in this article I have explained about following issues:

• LiveLock
• Priority Inversion

LiveLock

A thread often acts in response to the action of another thread. If the other thread’s action is also a response to the action of another thread, then livelock may result. As with deadlock, livelocked threads are unable to make further progress. However, the threads are not blocked; they are simply too busy responding to each other to resume work. A livelock happens when a request for an exclusive lock to use the shared resource is repeatedly denied because a series of overlapping shared locks keeps interfering and at the end two or more threads continue to execute, but make no progress in completing their tasks.

A livelock is very similar to a deadlock, except that the state of the two processes involved in the livelock constantly changes with regards to the other process.

As a real world example, livelock occurs when two people meet in a narrow corridor, and each tries to be polite by moving aside to let the other pass, but they end up swaying from side to side without making any progress because they both move always the same way at the same time. A deadlock results in an infinite wait whereas a livelock results in wasting CPU cycles.
Priority Inversion

Priority inversion occurs when two or more threads with different priorities are in contention to be scheduled.

Let’s understand:

When we have a shared resource, we use the lock (mutex) to prevent race conditions and inconsistencies. Locks make sure that only one thread is accessing the resource at a time. In order to access a resource a thread must acquire the lock first. If it is unable to acquire the lock (it means, another thread is using the resource), it must wait until the thread currently accessing the resource releases the lock. Now take a simple case with three threads:

• Thread 1 with High priority
• Thread 2 with low priority and
• Thread 3 with medium priority

Thread 3 is holding a lock on a resource that Thread 1 is wants to use. Thread 1 must wait for thread 3 to release the lock because it called acquire on the lock. Because thread 1 is waiting for the lock, it is not available to run. Thread 3 and 2 are ready to run. So when the priority scheduler chooses a thread to run next, it can only choose between 3 and 2. Thread 2 has a higher priority, so it will go next. Thread 3 cannot run, so it won’t be able to release the lock and thread 1 will have to wait until 2 finishes. In other words, the highest priority thread, thread 1, is inadvertently being blocked from running by a lower priority thread, thread 2.

I haved cover other two issues of multithreaded programming like “Two-Step Dances” and “Lock Convoys” in the “Issues with Multithreaded Programming – Part 3”.

Dont forget to read Issues with Multithreaded Programming: Part 1 to understand about:

• Race Condition
• DeadLock

3 Responses to “Issues with Multithreaded Programming: Part 2”

1. Jonny says:

   June 24, 2011 at 11:46 AM

   I have red the part 1 and was waiting for part 2. both are too good.

   looking forward to the next one…

   Thanks
2. Pankaj says:

   June 27, 2011 at 6:33 PM

   Its good to know about issues of Multitheading programming, like dead lock, LiveLock, race condition etc…
   Would you please add some information about how to handle these cases…
   This will help to prevent from thse issue…

   Thanks,
   Pankaj
3. Syed says:

   February 4, 2012 at 11:00 AM

   Nice explanation. It would be better if you give the solutions like for Race condition – Thread Synchronisation.

   Please check this order

   •Thread 1 with High priority
   •Thread 2 with low priority and
   •Thread 3 with medium priority

   It is conflicting with the explanation.