Don't agree with Peterson's solution

Question

#define FALSE 0
#define TRUE 1
#define N 2

int turn;
int interested[N];

void enter_region(int process) {
  int other;
  other = 1 - process;
  interested[process] == TRUE;
  turn = process; // set flag
  while (turn == process && interested[other] == TRUE)
}
void leave_region(int process) { interested[process] = FALSE; }

wouldn't it be a violation of the third criteria of critical regions if a clock interrupt ocurred after process 0 executed the statement

interested[process]==TRUE;

because process one would wait in the while loop in his whole processor time being blocked from processor 0 .

Perterson's solution or algoruthm is a famous concurrent programming algorithm for mutual exclusion that allows two processes to share a single-use resource without conflict, using only shared memory for communication.

the criteria i'm referring to is : No process running outside its critical region may block any process.

We have no idea what problem Peterson is trying to solve or what criteria is third in some list we've never seen. — David Schwartz, Nov 25 '15 at 19:44
Sorry , Perterson's solution or algoruthm is a famous concurrent programming algorithm for mutual exclusion that allows two processes to share a single-use resource without conflict, using only shared memory for communication. i was looking for an answer from someone that is familiar with this problem , because i've searched for an answer about this in my textbook about operating systems and i haven't found aan answer. the criteria i'm referring to is : No process running outside its critical region may block any process. — Amarildo Likmeta, Nov 25 '15 at 19:48
Why do you care whether the person who answers your question is familiar with the problem or not? That's also kind of rude to all the people not familiar with the problem who read your question and are just left baffled. (I was able to find the context using a search engine, but why make people go through that? If it's such a famous problem, it should be easy to find a link to it, no?) — David Schwartz, Nov 25 '15 at 19:55
any relevant information about the question should be added to the question, not in comments. I have edited your question by adding your comment to the end of it. You can [edit] it yourself if you wish to reformulate — bolov, Nov 25 '15 at 19:55

score 2 · Answer 1 · answered Nov 25 '15 at 19:49

2

A process that wants to enter the critical section must be blocked by a process that has not yet fully released it. That's the explicit purpose of the mutual exclusion algorithm.

The third criterion is that no process running outside the critical section may block other processes. Process one doesn't block other processes, and it can only be blocked by a process that hasn't yet released the critical section. So the third criterion is not violated.

If you still disagree, explain either how process one blocks other processes or how process one could be blocked by a process running outside its critical section.

answered Nov 25 '15 at 19:49

David Schwartz

179,497
17
214
278

Consider this example : process 0 calls enter_region routine , which itself is not part of the critical region . after executing the statement interested[process]=TRUE; a clock interrupt ocurs and the scheduler "gives" the CPU to process 1 . Process 1 also call enter_region it sets interested[1] to TRUE and turn to 1 . when it reaches theloop turn=1 dhe interested[0]=1 so process 1 will be negated access to the critical region even though process 0 isn't in its critical region . process 0 will too be negated access .Process 1 will enter the critical region at the third round . – Amarildo Likmeta Nov 25 '15 at 20:13
If a thread is guaranteed to be the next one to return from `enter_region`, then it has entered the critical region because it has already prevented any other thread from getting the region before it. If you consider the thread to have entered the critical region as soon as it set `interested[1]` to `TRUE`, there is no problem. The situation is the same as if the thread stopped running right as `enter_region` returned, which no algorithm could avoid (nor does it need to). – David Schwartz Nov 25 '15 at 20:26
enter_region isn't part of the critical region , or am I wrong? the critical region it's the block of code after the procedure enter_region i'm not claiming that process 1 will enter the CR the third round arbitrarily , but in that example following the algorithm that's what will happen. if the procedure enter_region was indivisible , meaning that it cannot be interrupted ,just like operations in a semaphore,there wouldn't be any problem , but i haven't found this condition anywhere. Thats why i asked the question in the first place. – Amarildo Likmeta Nov 25 '15 at 20:38
If that were true, you wouldn't be in the critical region right as `enter_region` returns, which can't possibly be right. The purpose of `enter_region` is for you to call it outside the critical region and for it to return inside it. Somewhere inside that function, the transition happens. It's the same with sempahores. What if the kernel decides to switch threads right as the acquire operation completes but before it can return to the caller? – David Schwartz Nov 25 '15 at 20:41
i'm not understanding you , are you saying that enter_region is part of the CR region or that it isn't ? a CR is a part of code that handles the shared memory . that being said there is no shared memory in the enter_region procedure so enter_region is not part of the critical region . I'm not stating this . this comes from my text book – Amarildo Likmeta Nov 25 '15 at 20:50
First, the `interested[N]` array must be shared memory or the algorithm won't work. Second, I'm saying that the purpose of `enter_region` is for you to call it outside the CR and it returns inside it (hence its name). So the transition occurs somewhere inside that function. – David Schwartz Nov 25 '15 at 20:52
Also think about what you're saying. Imagine this code :`enter_region(); func_1_that_deals_with_shared_memory(); printf("foo\n"); func_2_that_deals_with_shared_memory(); exit_region();` Are you really arguing that the `printf` is outside the CR because it doesn't deal with shared memory?! – David Schwartz Nov 25 '15 at 20:54
the array isn't shared memory because each process use different indexes of the array ,they never use the same data . the transition may also be after the return . The purpose of enter-region is to ensure a safe entrance in the CR . – Amarildo Likmeta Nov 25 '15 at 21:01
i'm arguing ,that just enter region is outside the CR – Amarildo Likmeta Nov 25 '15 at 21:06
`interested[other]` is accessed. And, in any event, as I showed, that would make any implementation impossible. – David Schwartz Nov 25 '15 at 21:17
it's read , not written . also if you consider enter_region as part of the CR then in this example both processes are in the critical region in the first place – Amarildo Likmeta Nov 25 '15 at 21:20
We need to switch to a forum or something. SO is not appropriate for this conversation. (Or ask another question.) I'm kind of baffled though why you continue to mis-state my position. How many times do I have to say, "the purpose of enter_region is for you to call it outside the CR and it returns inside it" and " the transition occurs somewhere inside that function"? – David Schwartz Nov 25 '15 at 21:23
look , i'm just saying that the transition doesn'y occur inside the function because if it was this the case then the two processes would be in their critical region at the same time breaching the first criteria . Understand? if you don't it's useless to continue this conversation – Amarildo Likmeta Nov 25 '15 at 21:31
They wouldn't be. One would be in the function before the transition and one would be in the function after. Of course you'd be right if two threads/processes could be in the function after the transition. But that can't be. The transition occurs as soon as the thread/process is guaranteed to be the next one to return from `enter_region` no matter what any other thread/process does. Also, shared memory is defined as memory that can be written by one thread/process and read by another, which is precisely how the `interested` array is used. – David Schwartz Nov 25 '15 at 21:34
in my example both processes wait at the loop at the end for their entire processor time , so if the transition occurs inside the function , as you state , both processes are after the transition or if the transition occurs after the return , both of them are before the transition and they're blocking each other . Either way one criteria is breached. – Amarildo Likmeta Nov 25 '15 at 21:40
There must be some process that is guaranteed to return from `enter_region` next. That process is in the CR and that's the one that's blocking the other two. If you could find a situation where there was at least one thread in `enter_region` and it could happen that no thread ever gets the CR even though no thread holds it, then you'd have found a problem. And, as I explained before, your argument would apply to any conceivable algorithm. All that has to happen is that a thread/process reaches the point where it blocks others then it gets de-scheduled. That even happens with semaphores. – David Schwartz Nov 25 '15 at 21:44
Tell me which process is guaranteed to return? You're not answering, you're avoiding the question. I'm not saying that this solution is not right, ofcourse peterson knew a thing or two more than me. I was just lookin for an explanation. – Amarildo Likmeta Nov 25 '15 at 21:46
For one of them, `turn == process` will be false, since `turn` is the same in both and `process` isn't. That one is guaranteed to return. That one is blocking the other. – David Schwartz Nov 25 '15 at 21:55

Don't agree with Peterson's solution

1 Answers1