Use the record semaphore mechanism to solve three classic problems of process synchronization
There are three classic problems in process synchronization : producer-consumer problem; dining philosophers problem; reader-writer problem
The first is the producer-consumer problem:
For details, see: Classic operating system problems - consumer-producer problem_Operating system producer-consumer problem_A blog about writing poems with programming-CSDN blog
First of all, what is the producer-consumer problem:
There are a set of producer processes and a set of consumer processes in the system. The producer process produces a product and puts it into the buffer every time, and the consumer process takes out a product from the buffer and uses it every time, so there is such a relationship between them.
Use record-type semaphores to solve the producer-consumer problem: Assume that there are n buffers in the public buffer pool between the producer and the consumer. In this case, the mutual exclusion semaphore mutex can be used to realize the mutual control of the buffer pool by the processes. Exclude use. Use the semaphore empty and full to represent the number of empty buffers and full buffers in the buffer pool respectively.
Initialization: semaphore mutex=1, empty=n, full=0; In the initial state, the mutex semaphore is 1 empty buffer and there are n non-empty buffers 0.
Producer produces:
producer (){
while(1)
{ Produce a product;
P(empty);//determine whether it is empty
P(mutex);//Determine whether it is possible to enter the critical section to find resources
Put product into buffer;
V(mutex);//Release resources in critical section
V(full); } //How many products are there in the non-buffer area}
P(mutex) and V(mutex) implement mutually exclusive access of the process, and P(empty) implements letting the buffer be full as a pre-production operation for the producer, that is, when empty=0, that is, when there is no free buffer, let the consumer Consumer consumption serves as the pre-operation of producer production.
V(full) realizes that the buffer is not empty as a pre-operation for consumer consumption, that is, when full=0, that is, when the buffer is all empty, the producer is allowed to produce as a pre-operation for consumer consumption.
Consumer consumption:
consumer(){
while(1)
{ p(full);//Determine whether there are products in the non-buffer area
p(mutex);//Determine whether it is possible to enter the critical section to find resources
Take the product out of the buffer and consume it
v(mutex);//Release the resources of the critical section
v(empty);//Add a position to the empty buffer}
P(mutex) and V(mutex) implement mutually exclusive access of the process, and V(empty) implements letting the buffer be full as a pre-operation for the producer to produce, that is, when empty=0, that is, when there is no free buffer, let the consumer Consumer consumption serves as the pre-operation of producer production.
P(full) realizes that the buffer is not empty as a pre-operation for consumer consumption, that is, when full=0, that is, when the buffer is all empty, the producer is allowed to produce as a pre-operation for consumer consumption.
In the producer-consumer problem, empty and full p and v operations need to appear in pairs, otherwise deadlock will occur.
For details on the dining philosophers problem and the reader-writer problem, see: Classic synchronization problems in operating systems - the reader-writer problem and the dining philosophers problem_A blog about writing poems with programming-CSDN blog
Next is the dining philosophers problem: the dining philosophers problem refers to five philosophers eating around a round table. But there are only 5 chopsticks. Usually when a philosopher is thinking about hunger, he tries to use the chopsticks closest to him on the left and right. Only when you have two chopsticks can you finish your meal and put down your chopsticks to think.
mutex[5] = {1,1,1,1,1}; //Initialize the semaphore
philosopher(){ while(1) { P(mutex[i]); //Take the chopsticks on the left
P(mutex[(i+1)%5]);//Take the chopsticks on the right
meal...
V(mutex[i]);//Replace the chopsticks on the left
V(mutex[(i+1)%5]);//Replace the chopsticks on the right
}
But when all the philosophers have taken the chopsticks on their left, there will be no chopsticks to take. At this time, a deadlock will occur. We have three solutions for this situation.
(1) Let up to 4 philosophers take the chopsticks on the left at the same time. Then one philosopher will definitely be able to release the chopsticks after finishing the meal, and others can use them normally.
(2) A philosopher is only allowed to pick up chopsticks to eat when he can get both left and right chopsticks at the same time.
(3) Mark the philosophers with serial numbers. The odd-numbered philosophers take the left chopsticks and then the right chopsticks, while the even-numbered philosophers do the opposite. Then according to the regulations, philosophers No. 1 and No. 2 compete for chopsticks No. 1, and philosophers No. 3 and No. 4 compete for chopsticks No. 3. That is, all philosophers compete for odd-numbered chopsticks first and then for even-numbered chopsticks. In the end, one philosopher will definitely get two. Eat with only chopsticks.
Finally, there is the reader-writer question:
In the reader-writer problem, the process that only reads the file is called the reader process, and the other processes are called writer processes. Allows multiple readers to read from one process at the same time but does not allow multiple writer processes to write at the same time or one writer to write to other readers to read.
We can see that the writer is mutually exclusive with other processes, so we can solve the problem by using a mutex Wmutex.
Writer(){
while(1){
P(Wmutex)
perform write operation
V(Wmutex)
}
}
Regarding the reader problem , we found that in this problem the reader is synchronized with the reader but is mutually exclusive with the writer. In this case, we set a readcount variable to record the number of readers. The judgment is based on the number of readers. If the number of readers is > 0, then only reader access can be performed at this time. Writer access cannot be performed every time. When operating on writers, we need to first determine the value of readcount. We also set a mutex semaphore for readers rmutex
Reader(){
while(1){
p(rmutex) //Each reading process has mutually exclusive access to readcount
if(readcount==0) p(Wmutex) //If there is currently no reader, the writer's operation can be performed
readcount++ //If readers apply, the quantity needs to be increased by one
v(rmutex)
Read the file... //The above part enables multiple readers to access the file at the same time. The next step is to exit when the reading process ends.
P(rmutex);//Each reading process has mutually exclusive access to raeadcount
readcount--;//Whenever a reading process completes a read operation, the number of readers -1
if(readcount==0) //If there is currently no reader, the writer's operation can be performed
V(wmutex);//When there is no reader and the reading operation ends, the writing process is unlocked
V(rmutex);
}
}