The following functions simulate the operation of buying tickets, and continue to buy tickets until they are sold out. The integer sum represents the current number of votes. The functions are as follows:

- (void)buyFunction {
//If you have spare tickets, continue to buy them.
while (sum > 0) {
//Print current votes before purchase
NSLog(@ "thread% @ ready to buy tickets remaining: %d tickets", [nThread Current Thread]. name, sum);
//Simulated purchase operation, votes -1
sum--;
}
//Print the current number of votes when the tickets are sold out.
NSLog(@ "thread% @: tickets have been sold out; remaining: %d tickets", [nThread Current Thread]. name, sum);
}
Now we open two threads to perform this operation at the same time, initially with 10 tickets (sum = 10), and check the console output:

2 Thread ready to buy tickets Remaining: 10 tickets
1 thread ready to buy tickets remaining: 10 tickets
1 thread ready to buy tickets remaining: 9 tickets
2 Thread ready to buy tickets Remaining: 8 tickets
1 thread ready to buy tickets remaining: 7 tickets
2 Thread ready to buy tickets Remaining: 6 tickets
1 thread ready to buy tickets remaining: 5 tickets
2 thread ready to buy tickets remaining: 4 tickets
1 thread ready to buy tickets remaining: 3 tickets
2 thread ready to buy tickets remaining: 2 tickets
1 thread ready to buy tickets remaining: 1 ticket
Thread 2: Tickets have been sold out. Remaining: 0 tickets
Thread 1: Tickets have been sold out. Remaining: -1 ticket
As a result of observation, we found some problems:
(1) The remaining votes in the two ticket buying processes are the same.
(2) I bought the same ticket twice.
(3) It was still bought once after there were no tickets left.
For the above example of ticket purchase, the whole process of ticket purchase is the critical section code, but we are missing the entry section, which can't guarantee the uniqueness of threads in the critical section, so there is a synchronization problem.
To solve the critical section problem, it is necessary to lock, which is similar to locking when a thread enters the critical section to prevent other threads from entering, and opening the lock to allow other threads to enter after the operation is completed. To solve the critical area problem, it is mainly to ensure mutually exclusive access of resources and avoid starvation.
Peterson algorithm provides a reasonable idea: set the flag array flag to mark the thread that requests to enter the critical area, set the turn to indicate the thread that can enter the critical area, and make a double judgment in the entry area, so that only one of the two threads will be reserved when assigning the turn at the same time, thus ensuring the mutual exclusion of resource access.
In the exit area, the flag flag is false, which ensures the "forward" principle and avoids other threads from starving due to continuous preemption of threads in the remaining area.