1. Chapter 5 Concurrency: 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. Difficulties of Concurrency
Sharing of global resources
consider two processes perform reads and writes on the same global variable
Optimally managing the allocation of resources is difficult
Difficult to locate programming errors as results are not deterministic and reproducible.

6. A Simple Example void echo()
Suppose echo is a shared procedure and P1 echoes ‘x’ and P2 echoes ‘y’
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?
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 Solution: Control access to shared resource
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. Race Condition A race condition occurs when
Multiple processes or threads read and write data items
They do so in a way where the final result depends on the order of execution of the processes
The output depends on who finishes the race last (the loser)
However, the processes and outputs must be independent of the processing speed

10. Process Interaction
Example: multiprogramming of multiple independent processes
Example: processes share access to some object, such as an I/O buffer
Example: Processes designed to work jointly on some activity

11. Competition among Processes for Resources
Three main control problems:
Need for Mutual Exclusion
Critical resource: nonsharable resource, e.g., printer
Critical section: portion of the program that uses a critical resource
Deadlock
Starvation

12. 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

13. 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

14. Roadmap Principals of Concurrency Mutual Exclusion: Hardware Support
Semaphores
Readers/Writers Problem

15. 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

16. Pseudo-Code while (true) { } /* disable interrupts */;
/* critical section */;
/* enable interrupts */;
/* remainder */; }
 Reduced interleaving
 Will not work in multiprocessor architecture

17. Special Machine Instructions
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; }

18. 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

19. 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

20. 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

21. Roadmap Principals of Concurrency Mutual Exclusion: Hardware Support
Semaphores
Readers/Writers Problem

22. 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)
increment (semSignal)

23. Semaphore Primitives

24. Binary Semaphore Primitives

25. Strong/Weak Semaphore
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

26. Mutual Exclusion Using Semaphores
The first process that executes a semWait will be able to enter the critical section immediately, setting the value of s to 0
Any other processes attempting to enter the critical section will find it busy and will be blocked

27. Processes Accessing Shared Data Using Semaphore
Three processes (A,B,C) access a shared resource protected by the semaphore lock.

28. 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

29. 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
Producer/Consumer Animation

30. Functions Assume an infinite buffer b with a linear array of elements
Producer
Consumer
while (true) {
/* produce item v */
b[in] = v;
in++; }
while (in <= out)
/*do nothing */;
w = b[out];
out++;
/* consume item w */

31. Buffer
The consumer must make sure that the producer has advanced beyond it (in > out) before proceeding
The producer can generate items and store them in the buffer at its own pace. Each time, in is incremented

32. Semaphores n is equal to the number of items in the buffer
Prevent the consumer and any other producer from accessing the buffer during the append operation
The consumer must wait on both semaphores before proceeding

33. Bounded Buffer
The buffer is treated as a circular storage; pointer values are expressed modulo the size of the buffer

34. Functions in a Bounded Buffer
in and out are initialized to 0 and n is the size of the buffer
Producer
Consumer
while (true) {
/* produce item v */
while ((in + 1) % n == out)
/* do nothing */;
b[in] = v;
in = (in + 1) % n }
while (in == out)
w = b[out];
out = (out + 1) % n;
/* consume item w */

35. Semaphores
e keeps track of the number of empty spaces

36. Demonstration Animations
Producer/Consumer
Illustrates the operation of a producer-consumer buffer.
Bounded-Buffer Problem Using Semaphores
Demonstrates the bounded-buffer consumer/producer problem using semaphores.

37. Roadmap Principals of Concurrency Mutual Exclusion: Hardware Support
Semaphores
Readers/Writers Problem

38. 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:
Multiple readers may simultaneously read the file
Only one writer at a time may write
If a writer is writing to the file, no reader may read it
interaction of readers and writers.

39. Readers have Priority readcount keeps track of the number of readers
x is used to assure that readcount is updated properly
the first reader that attempts to read should wait on wsem
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

40. 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

41. Writers have Priority y controls the updating of writecount
writecount controls the setting of rsem
rsem inhibits all readers while there is at least one writer desiring access to the data area

42. Writers have Priority
only one reader is allowed to queue on rsem, with any additional readers queuing on z

43. Writers have Priority

44. Key Terms 44