Post on 14-Dec-2015
transcript
1
Chapter 5Concurrency: Mutual Exclusion and
Synchronization
• Principals of Concurrency
• Mutual Exclusion: Hardware Support
• Semaphores
• Readers/Writers Problem
2
Multiple Processes
• Central to the design of modern Operating Systems is managing multiple processes– Multiprogramming
– Multiprocessing
– Distributed Processing
• Big Issue is Concurrency – Managing the interaction of all of these
processes
3
Interleaving and Overlapping Processes
• Earlier (Ch2) we saw that processes may be interleaved on uniprocessors
4
Interleaving and Overlapping Processes
• And not only interleaved but overlapped on multi-processors• Both interleaving and overlapping present the same
problems in concurrent processing
5
One Difficulty of Concurrency
• Sharing of global resources can be
problematic
6
A Simple Example
void echo()
{ // send a keyboard-input character to display
chin = getchar();
chout = chin;
putchar(chout);
}
What would happen if P1 is interrupted here by P2?
Suppose echo is a shared procedure and P1 echoes ‘x’ and P2 echoes ‘y’
What would happen if only one process is permitted at a time to be in the procedure?
7
A Simple Example: On a Multiprocessor
Process P1 Process P2
. .
chin = getchar(); .
. chin = getchar();
chout = chin; chout = chin;
putchar(chout); .
. putchar(chout);
. .
8
Enforce Single Access
• If we enforce a rule that only one process may enter the function at a time then:– P1 & P2 run on separate processors– P1 enters echo first,
• P2 tries to enter but is blocked
– P1 completes execution• P2 resumes and executes echo
Solution: Control access to shared resource
9
Competition among Processes for Resources
Three main control problems:• Need for Mutual Exclusion
– Only one program at a time be allowed in its critical section.
– Critical resource: nonsharable resource, e.g., printer
– Critical section: portion of the program that uses a critical resource
• Deadlock• Starvation
10
Requirements for Mutual Exclusion
• Only one process at a time is allowed in
the critical section for a resource
• A process that halts in its noncritical
section must do so without interfering with
other processes
• No deadlock or starvation
11
Requirements for Mutual Exclusion
• A process must not be delayed access to a critical section when there is no other process using it
• No assumptions are made about relative process speeds or number of processes
• A process remains inside its critical section for a finite time only
12
Roadmap
• Principals of Concurrency
• Mutual Exclusion: Hardware Support
• Semaphores
• Readers/Writers Problem
13
Disabling Interrupts
• Uniprocessors only allow interleaving
• Interrupt Disabling
– A process runs until it invokes an operating
system service or until it is interrupted
– Disabling interrupts guarantees mutual
exclusion because the critical section cannot
be interrupted
14
Pseudo-Code
while (true) {/* disable interrupts */;
/* critical section */;
/* enable interrupts */;
/* remainder */;
}
– Reduced interleaving – Will not work in multiprocessor architecture
15
Special MachineInstructions
• Use of atomic action: instruction is treated as a single step that cannot be interrupted– Compare&Swap Instruction
int compare_and_swap (int *word, int testval, int newval)
{ /* checks a memory location (*word) against a test value (testval) */
int oldval;oldval = *word;if (oldval == testval) *word = newval;return oldval;
}
16
Mutual Exclusion (fig 5.2)
• The only process that may enter its critical section is one that finds bolt equal to 0
• All other processes go into a busy waiting mode
17
Hardware Mutual Exclusion: Advantages
• Applicable to any number of processes on either a single processor or multiple processors sharing main memory
• It is simple and therefore easy to verify
• It can be used to support multiple critical sections
18
Hardware Mutual Exclusion: Disadvantages
• Busy-waiting consumes processor time
• Starvation is possible when a process leaves a critical section and more than one process is waiting– Some process could indefinitely be denied access
because selection of a waiting process is arbitrary
• Deadlock is possible– Example: P1 enters its critical section and is then
preempted by higher priority P2 which will go into a busy waiting loop
19
Roadmap
• Principals of Concurrency
• Mutual Exclusion: Hardware Support
• Semaphores
• Readers/Writers Problem
20
Semaphore
• Fundamental principle: Processes can cooperate by means of simple signal such that a process can be forced to stop at a specified place until it has received a specific signal.
21
Semaphore
• Semaphore: – An integer value used for signalling among
processes
• Only three operations may be performed on a semaphore, all of which are atomic: – initialize (to a nonnegative integer value)– decrement (semWait), to receive a signal– increment (semSignal), to transmit a signal
22
Semaphore Primitives
23
Binary Semaphore Primitives
24
Strong/WeakSemaphore
• A queue is used to hold processes waiting on the semaphore– In what order are processes removed from
the queue?
• Strong Semaphores use FIFO
• Weak Semaphores don’t specify the order of removal from the queue
25
Mutual Exclusion Using Semaphores
1. The first process that executes a semWait will be able to enter the critical section immediately, setting the value of s to 0
2. Any other processes attempting to enter the critical section will find it busy and will be blocked
26
Processes Accessing Shared Data Using
SemaphoreThree processes
(A,B,C) access a
shared resource
protected by the
semaphore lock.
27
Mutual Exclusion Using Semaphores
• The semaphore can be initialized to a
specified value to allow more than one
process in its critical section at a time
– s.count 0: the number of processes that
can execute semWait(s) without suspension
– s.count < 0: the magnitude is the number
processes suspended in s.queue
28
Producer/Consumer Problem
• General Situation:– One or more producers are generating data and
placing these in a buffer– A single consumer is taking items out of the buffer
one at time– Only one producer or consumer may access the
buffer at any one time
• The Problem:– Ensure that the Producer can’t add data into full buffer
and consumer can’t remove data from empty buffer
29
Functions
Producer Consumer
while (true) { /* produce item v */ b[in] = v; in++; }
while (true) { while (in <= out) /*do nothing */; w = b[out]; out++; /* consume item w */}
• Assume an infinite buffer b with a linear array of elements
30
Buffer
The producer can generate items and store them in the buffer at its own pace. Each time, in is incremented
The consumer must make sure that the producer has advanced beyond it (in > out) before proceeding
31
Semaphores
Prevent the consumer and any other producer from accessing the buffer during the append operation
n is equal to the number of items in the buffer
The consumer must wait on both semaphores before proceeding
32
Bounded Buffer
The buffer is treated as a circular storage; pointer values are expressed
modulo the size of the buffer
33
Functions in a Bounded Buffer
Producer Consumer
while (true) { /* produce item v */ while ((in + 1) % n == out) /* do nothing */; b[in] = v; in = (in + 1) % n}
while (true) { while (in == out) /* do nothing */; w = b[out]; out = (out + 1) % n; /* consume item w */}
in and out are initialized to 0 and n is the size of the buffer
34
Semaphores
e keeps track of the number of empty spaces
35
Roadmap
• Principals of Concurrency
• Mutual Exclusion: Hardware Support
• Semaphores
• Readers/Writers Problem
36
Readers/Writers Problem
• A data area (e.g., a file) is shared among many processes– Some processes (readers) only read the data
area, some (writers) only write to the area
• Conditions to satisfy:1.Multiple readers may simultaneously read the file
2.Only one writer at a time may write
3.If a writer is writing to the file, no reader may read it
37
Readers have Priority
wsem is used to enforce mutual exclusion: as long as one writer is accessing the shared data area, no other writers and no readers may access it
the first reader that attempts to read should wait on wsem
readcount keeps track of the number of readers
x is used to assure that readcount is updated properly
38
Readers/Writers Problem
• Once a single reader has begun to access the data area, it is possible for readers to retain control of the data area as long as there is at least one reader reading.– Therefore, writers are subject to starvation
• An alternative solution: no new readers are allowed access to the data area once at least one writer wants to write
39
Writers have Priority
rsem inhibits all readers while there is at least one writer desiring access to the data area
y controls the updating of writecount
writecount controls the setting of rsem
40
Writers have Priority
only one reader is allowed to queue on rsem, with any additional readers queuing on z
41
Writers have Priority
42
Key Terms