Question

We know that multi-threaded code has the bane of possible deadlocks if the threads acquire mutex locks but before it gets a chance to release it, the thread gets suspended by main thread or pre-empted out by Scheduler?

I am a beginner in using pthread library so please bear with me if my below query/proposed solution might be unfeasible or outright wrong.

void main()
{
    thread_create(T1,NULL,thr_function,NULL)

    suspend_thread(T1);

    acquire_lock(Lock1);<--- //Now here is a possible deadlock if thread_function acquried Lock1 before main and main suspended T1 before its release
    //Do something further;
}

void *thr_function(void *val)
{
    ///do something;
    acquire_lock(Lock1);
    //do some more things;
    //do some more things;
    release_lock(Lock1);

}

In this below pseudo code segment above I have, can’t the thread run-time/compiler work together to make sure if a thread which has acquired a mutex lock, is suspended/pre-empted then it executes some ‘cleanup code’ of releasing all locks it has held before it gets out. The compiler/linker can identify the places inside a thread function which acquire , release lock, then when a thread is suspended between those two places(i.e. after acquire but before release) the execution in the thread function should jump via some kind of ‘goto label;‘ inserted by the runtime where at the label: the thread would release the lock and then the thread gets blocked or context switch happens. [ I know if a thread acquires more than 1 locks it might get messy to jump across those points to release those locks…]

But basic idea/question is can the thread function not do the necessary releases of acquired locks for mutexes, semaphores before it gets blocked out or goes out of execution state to wait or some other state?

Answer 1

No. The reason a thread holds a lock is so that it can make data temporarily inconsistent or see a consistent view of that data itself. If some scheme were to automatically release that lock before the thread made the data consistent again, other threads would acquire the lock, see the inconsistent data, and fail. Or when that thread was resumed, it would either not have the lock or have the lock and see inconsistent data itself. This is why you can only reliably suspend a thread with that thread’s cooperation.

Consider this logic to add an object to a linked list protected by a mutex:

1. Acquire the lock protecting a linked list.
2. Modify the link’s head pointer.
3. Modify the object’s next pointer.
4. Release the lock.

Now imagine if something were to suspend the thread between steps 2 and 3. If the lock were released, other threads would see the link’s head pointer pointing to an object that had not been linked to the list. And when the thread resumed, it might set the object to the wrong pointer because the list had changed.

The general consensus is that suspending threads is so evil that even a feeling that you might want to suspend a thread suggests an incorrect application design. There is practically no reason a properly-designed application would ever want to suspend a thread. (If you didn’t want that thread to continue doing the work it was doing, why did you code it to continue doing that work in the first place?)

By the way, scheduler pre-emption is not a problem. Eventually, the thread will be scheduled again and release the lock. So long as there are other threads that can make forward progress, no harm is done. And if there are no other threads that can make forward progress, the only thing the system can do is schedule the thread that was pre-empted.