3 requirements for synchronization: why does this approach not work? - multithreading

Question

I'm trying to learn about synchornization and understand there are 3 conditions that need to be met for things to work properly
1)mutual exclusion - no data is being corrupted
2)bounded waiting - a thread won't do nothing forever
3)progress being made - system as a whole is doing work e.g. not just passing around who's turn it is
I don't fully understand why the code bellow doesn't work. According to my notes it has mutual exclusion but doesn't satisfy making progress or bounded waiting. Why? Each thread can do something and as long as now thread crashes everythread will get a turn.
The following are shared variables
int turn; // initially turn = 0
turn == i: Pi can enter its critical section
The code is
do {
while (turn != i){}//wait
critical section
turn = j;//j signifies process Pj in contrast to Pi
remainder section
} while (true);
It's basically slide 10 of these notes.

Answer 1

I think the important bit is that according to slide 6 of your notes the 3 rules apply to the critical section of the algorithm and are exactly as follows:
Progress: If no one is in the critical section and someone wants in,
then those processes not in their remainder section must
be able to decide in a finite time who should go in.
Bounded Wait: All requesters must eventually be let into the critical
section.
How to break it:
Pi executes and its remainder section runs indefinitely (no restriction for this)
Pj runs in its entirety, setting turn:= i so it's now Pi's turn to run the critical section.
Pi is still running its remainder which runs indefinitely.
Pj is back to it's critical section but never gets to run it since Pi never gets back to the point where it can give the turn to Pj.
That breaks the progress rule. No one is in the critical section, Pj wants in but cannot decide in a finite time if it can go in.
That breaks the bounded wait rule. Pj will never be let back in into the critical section.

Answer 2

As Malvavisco correctly points out, if a process never releases a resource no other process will have access to it. This is an uninteresting case and typically it's considered trivial. (In practice, it turns out not to be -- which is why there's a lot of emphasis on being able to manage processes from outside, e.g. forcibly terminate a process with minimal ill effects.)
The slides are actually a little imprecise in their definitions. I find that this Wikipedia page on Peterson's algorithm (Algorithm #3 on slide 12) is more exact. Specifically:
Bounded waiting means that "there exists a bound or limit on the number of times that other processes are allowed to enter their critical sections after a process has made a request to enter its critical section and before that request is granted"
Some thought experimentation makes it pretty clear that Algorithm #1 (slide 10) fails this. There is no bound on the number of times the critical section could be entered by either process if the process switching timing was unfortunate. Suppose process 1 executes, enters the critical section, and from there on process 2 only is switched to while process 1 is in its critical section. Process 1 will never account for this. Peterson's algorithm will as process 1 will forfeit its ability to enter the critical section if process 2 is waiting (and vice versa).