26
testAndSet instruction: take out the memory value, set it to True, and return the original value of the memory
while loop is critical section
Assuming that the lock was originally false, it is true after executing the atomic TestAndSet, and returning false will enter the critical section. At this point, another process accesses TestAndSet and returns true (guarantee that no two processes will acquire the lock)
Many operating systems wrap while(TestAndSet(&lock)) as a system call. When a process accesses a critical resource, the system call is called, and the process locks successfully and enters the critical area, otherwise it will keep looping.
27. Thread:
Create a thread pthread_create(); The third parameter is a function pointer, which will be executed after the thread is created.
28.
pthread_mutex_lock(&mutex) --- Add a mutex lock, the thread will return after acquiring the lock, otherwise it will block
pthreadd_mutex_lock(&mutex)
29.
Semaphore (semaphore): is an integer, and two operations P() and V() are assigned to this integer, adding one and subtracting one respectively
wait() -- +1
wait(S) {
while S<=0
;
S--;
}
signal() --- -1
signal(S){
S++；
}
wait and signal are atomic operations
Semaphore mutex = 1;
Pi(){
wait(mutex);
Critical Section;
signal(mutex);
}
Incoming mutex=1, while does not hold, S-- then exits, and then executes the code in the critical section. Finally S++.
When multiple processes use the semaphore, only one process can exit wait (because wait and signal are both atomic operations)
Counting semaphore: Mutex is not defined as 1 but 2 at the beginning, so that 2 processes can enter the critical section at the same time
There is no instruction to directly implement the semaphore, the implementation of the semaphore:
switch interrupt, TestAndSet
In the implementation in the code example, the process entering the critical section will continue to execute an infinite loop (Busy waiting), consuming CPU, also called spin lock.
Solution:
When busy waiting, the process is switched from the running state to the waiting state. redefine semaphore
struct semaphore{
int value;
struct process* waiting_list; //Execute the pointer of the PCB, use the pointer to construct a linked list, and use the linked list to string together the threads waiting for this semaphore. When the process can wake up, take it from the linked list
}
The idea of avoiding busy waiting in the operating system is similar. Each device builds a linked list and links all the PCBs waiting for this device together.
Use two system calls:
Block(); //Block the current process
WakeUp(P); //Wake up a process
/*
//Before, wait and then reduce
wait(S) {
while S<=0
;
S--;
}
*/
//Assuming that the semaphore is 1, the first process value--, does not enter if, does not block, and enters the critical section. The second process value-- is -1; blocking
Wait(Semaphore *S){
S -> value--;
if(S -> value < 0){
add this process to S -> list;
block();
}
}
/*
signal(S){
S++；
}
*/
//value is -n means that there are n processes blocked here
Signal(Semaphore *S){
S ->value++;
if(S -> value <=0){
remove a process from S -> list;
wakeup(P);
}
}
31.
Several thread synchronization issues:
Producer-consumer problem:
Two semaphores:
Semaphore mutex is initially 1
Semaphore full is initially 0
Semaphore empty is initially N (buffer size)
//producer
while(true){
//produce an item
wait(empty);
wait(mutex);
//add an item to buffer
signal(mutex);
signal(full);
}
//consumer
while(true){
wait(full);
wait(mutex);
//remove an item frm buffer
signal(mutex);
signal(empty);
//consume the removed item
}
analyze:
The role of mutex is to ensure the consistency of buffer data, and only one thread can modify shared variables.
Producer:
At the beginning, the value of empty is n, and the producer waits for an empty (n>0, if the condition does not hold), and will not block. It will block when the n+1th producer waits.
signal(full)，使full++。
consumer:
At first full is 0, wait(full) will block.
Ditto
Reader and Writer problem: simultaneous reading of writer causes data inconsistency
Define a semaphore:
Semapohre mutex is initially 1
Semaphore wrt is initially 1
integer
Integer readcount is initially 0
//writer
while(true){
wait(wrt);
//writing
signal(wrt);
}
//reader
while(true){
wait(mutex);
readcount ++;
if(readcount == 1) wait(wrt);
signal(mutex);
//reading
wait(mutex);
readcount--;
if(readcount == 0) signal(wrt);
signal(mutex);
}
analyze:
The wait and signal of mutex are the protection of readcount
Reader requires readcount++ before reading; readcount is the number of reads
If readcount==1 indicates that this is the first reader, it will wait for the wrt lock. (Write not allowed)
At this time, there is another reader, readcount++, if the condition is not established, it can be read directly.
After the reader finishes reading, it will readcount--, until the readcount is 0, and there is no reading process, the wrt lock will be released;
In general, the first read closes the write door, and the last read opens the write door.
Problem: too many reading processes cause the writing process to have no chance to execute (for shared memory backup, one read and one write)
The Philosopher's Dining Problem
32. Monitors --- A method of critical section protection implemented at the language level.
Various OS support for synchronization:
Solaris：
Adaptive mutexes (adaptive mutex lock): spin a few times first, enter the waiting queue if the lock cannot be obtained
Windows XP：
switch interrupt
Linux: Preemptive switching of the kernel.