Concurrency: Mutual Exclusion and Synchronization

1
Concurrency Mutual Exclusion and Synchronization

• Chapter 5

2
Concurrency

• Characteristics of concurrent / interleaved
  processes
• share/compete for resources
• communicate
• synchronize their activities

3
Concurrency

• Same problems in multiprogramming and
  multiprocessing
• Basic method to support concurrency
• mutual exclusion
• the ability to exclude all other processes from a
  course of action while one process is engaged in
  that action

4
A Simple Example

• void echo()
• chin getchar()
• chout chin
• putchar(chout)

5
one processor case
The echo procedure and its variables are shared
by two processes P1 and P2 P1 chin
getchar() // user types x interrupted, chin
contains x P2 chin getchar() // user
types y chout chin
putchar(chout) // y is displayed interru
pted, chin contains y P1 chout chin
putchar(chout) // y is displayed
instead of x
6
two-processors case

• Process P1 Process P2
• . .
• in getchar() .
• . in getchar()
• chout chin chout chin
• putchar(chout) .
• . putchar(chout)
• . .

7
Operating System Concerns

• Keep track of active processes
• Allocate and deallocate resources
• Processor time
• Memory
• Files
• I/O devices
• Protect data and resources
• Result of process must be independent of the
  speed of execution of other concurrent processes

8
Process Interaction

• Processes unaware of each other
• Independent
• competition for resources
• Processes indirectly aware of each other
• share access to some object
• cooperation
• data coherence problem
• Process directly aware of each other
• work jointly on some activity
• communicate via messages to coordinate activities
• cooperation

9
Control problems

• Mutual exclusion
• Two processes require access to a single
  non-shareable resource.
• Critical resource - the resource in question.
• Critical section in the program - the portion in
  the program that uses the resource
• The rule only one program at a time be allowed
  in its critical section

10
Deadlock

• Deadlock
• Involves at least two processes
• P1 waits for an event to be produced by P2
• P2 waits for an event to be produced by P1

11
Starvation

• Starvation
• Involves at least three processes P1, P2, P3,
  competing for non-shareable resource
• P1 and P2 alternatively use the resource
• P3 may indefinitely be denied access to that
  resource.

12
Competition Among Processes for Resources

• Mutual Exclusion
• Critical sections
• Only one program at a time is allowed in its
  critical section
• Example only one process at a time is allowed to
  send command to the printer
• Deadlock
• Starvation

13
Cooperation Among Processes by Sharing

• Writing must be mutually exclusive
• Critical sections are used to provide data
  integrity

14
Cooperation Among Processes by Communication

• Messages
• Mutual exclusion is not a control requirement
• Possible to have deadlock
• Each process waiting for a message from the other
  process
• Possible to have starvation
• Two processes sending message to each other while
  another process waits for a message

15
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 non-critical section
  must do so without interfering with other
  processes
• No deadlock or starvation
• Grant 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

16
Mutual Exclusion - software approaches
First attempt Processes P0 and P1, global
variable turn If turn 0, P0 can enter its
critical section If turn 1, P1 can enter its
critical section while (turn ! 0) / do
nothing / / critical section / turn
1
17
First attempt

• Each process enters its critical section and then
  transfers the access (by changing the value of
  turn) to the other process.
• busy waiting- while waiting to enter the
  critical section the process repeatedly checks
  the status of its permission (reads the value of
  turn)
• guarantees mutual exclusion
• Drawbacks
• processes must strictly alternate reducing the
  speed of execution
• if one process fails the other is permanently
  blocked.

18
Second attempt
Using a separate variable for each process whose
contents determine whether a process is in use of
its critical section or not while (flag1)
/ do nothing / flag0 true /
critical section / flag0 false No mutual
exclusion however, due to the possibility of
interleaving the operations for status checking
and status changing
19
Third Attempt

• Set flag to enter critical section before
  checking other processes
• flag0 true
• while (flag1)
• / do nothing /
• / critical section /
• flag0 false

20
Third Attempt

• If another process is in the critical section
  when the flag is set, the process is blocked
  until the other process releases the critical
  section
• Deadlock is possible when two process set their
  flags to enter the critical section. Now each
  process must wait for the other process to
  release the critical section

21
Fourth Attempt

• A process sets its flag to indicate its desire to
  enter its critical section but is prepared to
  reset the flag
• flag0 true
• while (flag1)
• flag0 false
• / delay /
• flag0 true
• / critical section /
• flag0 false.

22
Fourth Attempt

• This is not working due to the possibility of
  interleaving the operations for status changing
  and status checking.
• There is a situation when none of the processes
  would be able to enter its critical section,
  similar to the situations described above.

23
Correct Solution

• Each process gets a turn at the critical section
• If a process wants the critical section, it sets
  its flag and may have to wait for its turn

24
Dekkers algorithm
flag0 true //indicate the need to enter
// critical section while
(flag1) //while the other process is //
also entering if (turn 1) // if it is its
turn flag0 false //reset the
flag to false while (turn 1) // wait
while it is still // its turn /
do nothing / flag0 true
//indicate entering the // critical
section / critical section / turn
1 //give the turn to the other process flag 0
false //change status
25
Petersons algorithm
flag0 true //indicate the need to //
enter critical section turn 1 //grant the
turn to the // other process while (flag1
turn 1) //mutual exclusion / do
nothing / / critical section
/ flag 0 false //change status
26
Mutual ExclusionHardware Support

• Interrupt Disabling
• Disabling interrupts guarantees mutual exclusion
• Processor is limited in its ability to interleave
  programs
• Multiprocessing
• disabling interrupts on one processor will not
  guarantee mutual exclusion

27
Mutual ExclusionHardware Support

• Special Machine Instructions
• Performed in a single instruction cycle
• Not subject to interference from other
  instructions
• Reading and writing
• Reading and testing

28
Mutual Exclusion Machine Instructions

• 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

29
Mutual Exclusion Machine Instructions

• Disadvantages
• Busy-waiting consumes processor time
• Starvation is possible when a process leaves a
  critical section and more than one process is
  waiting.
• Deadlock
• If a low priority process has the critical region
  and a higher priority process needs, the higher
  priority process will obtain the processor to
  wait for the critical region

30
Semaphores

• The setting
• Special variable called a semaphore is used for
  signaling
• If a process is waiting for a signal, it is
  suspended until that signal is sent
• Wait and signal operations cannot be interrupted
• Queue is used to hold processes waiting on the
  semaphore

31
Semaphores

• Semaphore is a variable that has an integer value
• May be initialized to a nonnegative number
• Wait operation decrements the semaphore value
• Signal operation increments semaphore value

32
Semaphore types

• Binary semaphore - binary values 0 and 1.
• Strong semaphore - a semaphore whose definition
  includes the policy of first-in-first-out (FIFO)
  queue.
• Weak semaphore - a semaphore that does not
  specify the order in which processes are removed
  from the queue.
• Strong semaphores guarantee avoiding starvation.

33
Example Barbershop Problem
34
Mutual exclusion with semaphores
Each process performs wait(s) / critical
section / signal(s)
35
Producer/Consumer Problem

• 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

36
Producer/Consumer Problem Infinite Buffer
37
Circular Buffer
38
Producer

• producer
• while (true)
• / produce item v /
• bin v
• in

39
Consumer

• consumer
• while (true)
• while (in lt out)
• /do nothing /
• w bout
• out
• / consume item w /

40
Producer/Consumer Problem

• the consumer takes an item only if one is
  available
• a semaphore that prevents the consumer from
  reading when the buffer is empty (n out - in)
• mutual exclusion is not ensured
• solution
• a semaphore that allows only one
  producer/consumer to perform write/read

41
Producer/Consumer Problem
s - semaphore for entering the critical
section delay - semaphore to ensure reading from
non-empty buffer Producer Consumer
produce() wait(delay) wait
(s) wait(s) append() take() signal(dela
y) signal(s) signal(s) consume()

42
Monitors

• Monitor is a software module
• Chief characteristics
• Local data variables are accessible only by the
  monitor
• Process enters monitor by invoking one of its
  procedures
• Only one process may be executing in the monitor
  at a time

43
(No Transcript)
44
Monitors

• synchronization - condition variables contained
  within the monitor and accessible only from
  within the monitor.
• cwait(c)
• csignal(c)
• The advantage that monitors have over semaphores
  is that all of the synchronization functions are
  confined to the monitor.

45
Monitors

• cwait(c) Suspend execution of the calling
  process on condition c. The monitor is now
  available for use by another process.
• csignal(c) Resume execution of some process
  suspended after a cwait on the same condition.
  If there are several such processes, choose one
  of them if there is no such process, do nothing.

46
Message Passing

• Enforce mutual exclusion
• Exchange information
• send (destination, message)
• receive (source, message)

47
Synchronization

• Sender and receiver may or may not be blocking
  (waiting for message)
• Blocking send, blocking receive
• Both sender and receiver are blocked until
  message is delivered
• Called a rendezvous

48
Synchronization

• Nonblocking send, blocking receive
• Sender continues processing such as sending
  messages as quickly as possible
• Receiver is blocked until the requested message
  arrives
• Nonblocking send, nonblocking receive
• Neither party is required to wait

49
Addressing

• Direct addressing
• send primitive includes a specific identifier of
  the destination process
• receive primitive could know ahead of time which
  process a message is expected
• receive primitive could use source parameter to
  return a value when the receive operation has
  been performed

50
Addressing

• Indirect addressing
• messages are sent to a shared data structure
  consisting of queues
• queues are called mailboxes
• one process sends a message to the mailbox and
  the other process picks up the message from the
  mailbox

51
(No Transcript)
52
Message Format
53
Queuing Discipline

• First-in-first-out
• Specifying message priority
• Allow receiver to inspect message queue and
  select which message to receive next.

54
Mutual exclusion via messages
Process receive(mutex, msg) / critical
section / send(mutex, msg) Main
program create_mailbox(mutex) send(mutex,null
) parbegin(P(1),)
55
Readers/Writers Problem

• Any number of readers may simultaneously read the
  file
• Only one writer at a time may write to the file
• If a writer is writing to the file, no reader may
  read it

56
Readers have priority
Since the reading is not mutually exclusive, if
someone is reading, any other can join the
reading. Writers are potentially subjected to
starvation. Semaphore wsem - guarantees only
one writer and mutually excludes reading and
writing.
57
Readers have priority

• The algorithm
• Only the first reader and each writer wait on
  wsem.
• The last reader and each writer signal wsem.
• Readers count their number in a variable
  readcount. To prevent simultaneous updating, they
  use a semaphore x

58
Initially wsem and x are set to 1, readcount is 0.
/ program readerswriters / int readcount
semaphore x 1, wsem 1
/ main / void main() readcount 0
parbegin (reader, writer)
59
/ readers / wait(x) readcount if (readcount
1) wait (wsem) signal(x) READUNIT() wait
(x) readcount-- if (readcount 0)
signal(wsem) signal(x)
/ writers / wait(wsem) WRITEUNIT()
signal(wsem)
60
Writers have priority
The first writer that comes blocks the subsequent
readers from joining the reading pool until all
writers finish their job.
rsem - to prevent subsequent readers from joining
the reading pool. It is set by the first writer,
and released by the last writer y - to prevent
simultaneous updating of writecount z - to
queue the subsequent readers
61
/ program readerswriters / int readcount
semaphore x 1, y 1, z 1,
wsem 1, rsem 1
/ main / void main() readcount
writecount 0 parbegin (reader, writer)

62
/ readers / wait(z) wait(rsem) wait(x) readco
unt if (readcount 1) wait
(wsem) signal(x) signal(rsem) signal(z) READUN
IT() wait(x) readcount-- if (readcount 0)
signal(wsem) signal(x)
/ writers / wait(y) writecount if
(writecount 1) wait (rsem) signal(y) wait
(wsem) WRITEUNIT() signal(wsem) wait(y) writec
ount-- if (writecount 0)
signal(rsem) signal(y)
63
Alternative solution with messages

• The basic idea
• Send message to request access
• Receive message that grants the access
• Do the jib
• Send message to indicate finished job.

64
Controller process
readrequest queue writerequest queue finished
queue a variable count is used for
scheduling. Writers have priority
65
count
Count gt 0 Only readers in action.
At each finished message count is decremented by
1. Count lt 0 At least one writer is waiting. The
controller clears the finished queue,
incrementing count until it becomes 0. Count
0 The pending writer is granted access. The
controller waits to receive a finished message,
before proceeding. Count is set to 100.