Why is this Mutex solution incorrect?

Question

There are 2 processes P1 and P2 that can enter the Critical Section.

Mutex Solution Requirements:

A Mutex Zone - (Critical Section) that can only hold one process maximum.

No Mutual Blocking - a process outside the critical section cannot block a process inside it.

No Starvation - a process interested in entering the critical section must not have to wait forever.

Success without Contention - a process interested in entering the critical section must succeed in doing so if there are no other processes interested.

Why is the below code an incorrect solution to the Mutual Exclusion problem?

i.e. which requirement does it not satisfy?

C1 and C2 are initialised to 1.

P1:  LOOP
        Non-Critical Section
        LOOP UNTIL C2 = 1 END_LOOP;
        C1 := 0;
        Critical Section
        C1 := 1;
END

P2:  LOOP
        Non-Critical Section
        LOOP UNTIL C1 = 1 END_LOOP;
        C2 := 0;
        Critical Section
        C2 := 1;
END

@paddy I'm trying to figure out why this solution doesn't work and I've been scratching my head for over 2 hours :( — Naomi, Apr 23 '16 at 11:38
Maybe wrong, but C1 and C2 can still be uninitialized when P1 and P2 first try to loop on them. Also, even if they were initialized with 0, the processes can deadlock (i.e. block each other) as both are waiting for the other to reach the end. If I understand the context correctly. — Margaret Bloom, Apr 23 '16 at 11:40
@MargaretBloom I forgot to add that C1 and C2 are initialised to 1!!! — Naomi, Apr 23 '16 at 11:41
but... no atomic operations? P1 and P2 can enter the critical section at the same time. There's a race condition on C1 and C2 with no atomics. — Margaret Bloom, Apr 23 '16 at 11:46
AHH I SEE, silly me >_> yeah you're right, if P1 and P2 enter at the same time, MUTEX is not enforced. Thanks! — Naomi, Apr 23 '16 at 11:46
@MargaretBloom I think that the crazy pseudocode style means we are supposed to overlook normal things that we worry about. In fact, I believe the answer is not that. It's about starvation. And you possibly get extra points for mentioning non-atomic side-effects that could lead to starvation. — paddy, Apr 23 '16 at 11:47
@paddy I thought about starvation too haha, but how would it apply in this case? :O — Naomi, Apr 23 '16 at 11:47
@paddy, the two process only try to access the CS once. I don't think there can be starvation. Starvation applies when more than one process repeatedly try to acquire (a denied) resource. There can be a deadlock of course, if any of the processes loop in the CS, the other one cannot enter. Maybe it's me but I won't call that starvation. — Margaret Bloom, Apr 23 '16 at 11:52
I may have misread the question. I just assumed that when I saw "Critical section", it was code that caused a lock. Now I realise it's intended as a naive mutex implementation where the critical stuff happens in that part. Still, the starvation can occur if P2 restores `C2` back to 1 before P2 gets any processor time, thus remaining in that spin-wait. — paddy, Apr 23 '16 at 11:55
@MargaretBloom I thought a deadlock can only occur when Process A holding Resource A is requesting for Resource B and Process B holding Resource B is requesting for Resource A? — Naomi, Apr 23 '16 at 11:55
@Naomi yes. A never ending loop in the CS maybe it's not called a deadlock, I call deadlock every situation where no more process can proceed. I'm a not an expert, don't learn from me :) — Margaret Bloom, Apr 23 '16 at 12:00
@MargaretBloom but you answered my question, so thanks lol! :) — Naomi, Apr 23 '16 at 12:14

paddy · Accepted Answer · 2016-04-23T12:25:19.400

To interpret the question with the best of intentions, I would have to assume that each read or write is deemed to be atomic and well-ordered. Then it makes more sense.

The problem you have here is that the inner loop in each process can independently complete. Those loops are the "wait for my turn" part of the mutex.

However, the terminating of that loop and the following assignment (which would stop the other loop from terminating) are not atomic. We therefore have the following possible scenario:

P1: exit wait loop because C2 is 1

P2: exit wait loop because C1 is 1
P2: set C2 to 0
P2: enter critical section

P1: set C1 to 0
P1: enter critical section

The above violates that first requirement of having a Mutex Zone. Conditions that lead to such a violation are commonly known as a race condition.

You could also expect one process to starve the other. There is a possibility that P2 will always execute its critical section and acquire the lock again before P1 (who is waiting for the lock) gets a slice of CPU time. The control variable C2 would therefore always be 0 as seen by P1. Or at least, may be that way for a disproportionate number of slices.

P2: exit wait loop because C1 is 1
P2: set C2 to 0

P1: spin on C2 != 1 for entire time slice

P2: enter critical section
P2: set C2 to 1
P2: exit wait loop because C1 is 1
P2: set C2 to 0

P1: spin on C2 != 1 for entire time slice

P2: enter critical section
P2: set C2 to 1
P2: exit wait loop because C1 is 1
P2: set C2 to 0

P1: spin on C2 != 1 for entire time slice

...

Except in some environments, it's unlikely that P1 would be starved forever. But since P1 has asserted that it is waiting, it should not expect P2 to get multiple cracks at the critical section before it gets a turn.

This might also be a violation of the Success Without Contention requirement, but that's hard to argue really. But I would suggest that if P2 is no longer running, then consider what state C2 might be left in, and why P1 should need to know about P2 at all.

Why is this Mutex solution incorrect?

1 Answers1