626 views
1. The Operations P(S) & V(S) needs to be atomic.
2. A process exiting the CS will call V(S)
3. ‘Busy-Wait’ solutions to the Critical Section are typically implemented using machine instructions that execute in the Kernel mode
4. All of the above

The correct answer given for this question is (4) All of the above. And explaination is given as:

All the given statements are Basic definitions of Synchronization constraints

But I had a doubt regarding option number 3. I think this option is incorrect.

My thought process here is:

1. context switching is initiated is via interrupts caused by external or internal events. Example, in round-robin scheduling, when the time quanta is over, a timing device will trigger an interrupt which will intitate the context-switch of the process.
2. instructions running in the kernel mode generally have IEN = 0 (interrupt enable flag set to zero i.e. interrupts disabled) and hence they cannot be interrupted. Effectively they cannot be pulled out of execution until a particular block of code is completely executed.

Taking the above two points, a "Busy-wait" solution of synchronization implemented in kernel mode might get stuck in execution and never come out of execution (i.e. will not get preempted). And hence option number (3) is incorrect.

For example, a busy-waiting code like:

while (x == 0);        // x currently is 0

CS

if executed in kernel mode, will not be preempted and the "other" processes that sets x to a non-zero value (and allow the above process to enter the critical section) will never be able to run.

edited | 626 views
0
I don't think,

2. A process exiting the CS will call V(S)

is always necessary  ?
0
Then, what it will do by keeping the resource, when it comes out of CS ?
0
@vijaycs: yes, I thought so too. it isn't necessary and that is why I went with the option (1) which turned out to be incorrect answer for the above question.

Anyways, the third option is the one that is spinning my head. Your thoughts?
0
We can call

P(S)

C.S.

P(S)

So, 2) may be true or may not be.

3) is correct, as C.S. code cannot be implemented in user mode. In Kernel mode it typically run by the code, written by programmer.

Correct me if wrong.
0
@srestha
What is your exit condition then ? How will another process enter CS next ?

Whenever a process wants to execute its critical section it has to first check if it is allowed to enter critical section or not in Entry Section. If it gets access then it has to notify all other processes that the critical section is used by it. Once it has used the critical section, it notifies other processes that the critical section is ready to be used through the Exit Section .

So I think option 2 is also correct .

Option 1 and 2 are apt

The Operations P(S) & V(S) needs to be atomic.

This is True . Semaphore Operations Wait & Signal are always atomic

A process exiting the CS will call V(S)

This is true . Process entering CS is by aquiring resourses  and leave CS by releasing the CS.

3.‘Busy-Wait’ solutions to the Critical Section are typically implemented using machine instructions that execute in the Kernel mode
This is also not always necessary

Busy Waiting Solution Of Critical Sections Problems are of Two Types

• Busy Waiting
• Non-Busy Waiting

In Busy Waiting there are many solutions . Of which includes

• Harware Implemetation
1. TSL
2. SWAP
• Software Implementation
1.  Lock Variable
2. Strict Alternation
3. Peterson Solutions
4. Dekkers Algorithm
by Boss (21.5k points)
edited by
+2
i think option 2 is correct.....process existing the CS should definitly leave the resources it was holding
0
Hi pC, thanks for the answer.

I was curious to know whether my concepts/thought process regarding this question were correct or not. From your explaination, its seems my assumptions were not correct. Can you please look at the two points I have mentioned in the question (below the dotted line)? I would be grateful to know your views on them. Thanks :)
0
Option C is incorrect for e.g in the case of Peterson solution which is busy waiting solution but here we don't any privileged instructions that need to be executed in kernel mode.