Concurrency: Mutual Exclusion and Synchronization

1
Concurrency Mutual Exclusion and Synchronization

• Fred Kuhns

2
Concurrency

• Communication among processes
• Sharing resources
• Synchronization of multiple processes
• Allocation of processor time

3
Difficulties with Concurrency

• Sharing global resources
• Management of allocation of resources
• Programming errors difficult to locate

4
Example Race Conditions

• Two processes want to access shared memory at
  same time
• Solution Synchronize Access

5
Operating System Concerns

• Result of processing must be independent of the
  speed of execution
• Process Interactions
• Processes unaware of each other
• Compete for resources
• Processes indirectly aware of each other
• Cooperation by sharing
• Process directly aware of each other
• Cooperation by communication

6
Competition for Resources

• Problem Execution of one process may affect the
  behavior of competing processes
• Solution Mutual Exclusion
• a critical section is the fragment of code that
  accesses shared data
• when one process is executing in its critical
  section, no other process is allowed to execute
  in its critical section
• Issue Deadlock and Starvation
• blocked process will never get access to the
  resource and never terminate

7
Mutual Exclusion Requirements

• Mutually exclusive access to critical section
• Progress. If no process is executing in its
  critical section and there exist some processes
  that wishes to enter their critical section, then
  the selection of the processes that will enter
  the critical section next cannot be postponed
  indefinitely.
• Bounded Waiting. A bound must exist on the
  number of times that other processes are allowed
  to enter their critical sections after a process
  has made a request to enter its critical section
  and before that request is granted.
• Assume each process executes at a nonzero speed
• No assumption concerning relative speed of n
  processes.

8
Cooperation by Sharing

• Processes use and update shared data such as
  shared variables, files, and data bases
• Writing must be mutually exclusive
• Critical sections are used to provide data
  integrity

9
Cooperation by Communication

• Communication provides a way to synchronize, or
  coordinate, the various activities
• no sharing gt mutual exclusion not required
• 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

10
Consumer Producer Example

• Bounded Buffer Problem
• Shared data
• define BUFFER_SIZE 10
• typedef struct
• . . .
• item
• item bufferBUFFER_SIZE
• int in 0
• int out 0
• int counter 0

11
Producer Process

• item nextProduced
• while (1)
• while (counter BUFFER_SIZE)
• / do nothing /
• bufferin nextProduced
• in (in 1) BUFFER_SIZE
• counter

12
Consumer Process

• item nextConsumed
• while (1)
• while (counter 0)
• / do nothing /
• nextConsumed bufferout
• out (out 1) BUFFER_SIZE
• counter--

13
Bounded Buffer

• The statementscountercounter--must be
  performed atomically.
• Atomic operation means an operation that
  completes in its entirety without interruption.

14
Bounded Buffer

• The statement count may be implemented in
  machine language asregister1 counter
• register1 register1 1counter register1
• The statement count may be implemented
  asregister2 counterregister2 register2
  1counter register2

15
Bounded Buffer

• If both the producer and consumer attempt to
  update the buffer concurrently, the assembly
  language statements may get interleaved.
• Interleaving depends upon how the producer and
  consumer processes are scheduled.

16
Bounded Buffer

• Assume counter is initially 5. One interleaving
  of statements isproducer register1 counter
  (register1 5)producer register1 register1
  1 (register1 6)consumer register2 counter
  (register2 5)consumer register2 register2
  1 (register2 4)producer counter register1
  (counter 6)consumer counter register2
  (counter 4)
• The value of count may be either 4 or 6, where
  the correct result should be 5.

17
Race Condition

• Race condition The situation where several
  processes access and manipulate shared data
  concurrently. The final value of the shared data
  depends upon which process finishes last.
• To prevent race conditions, concurrent processes
  must be synchronized.

18
Initial Attempts to Solve Problem

• Only 2 processes, P0 and P1
• General structure of process Pi (other process
  Pj)
• do
• entry section
• critical section
• exit section
• reminder section
• while (1)
• Processes may share some common variables to
  synchronize their actions.

19
Algorithm 1

• Shared variables
• int turninitially turn 0
• turn - i ? Pi can enter its critical section
• Process Pi
• do
• while (turn ! i)
• critical section
• turn j
• reminder section
• while (1)
• Satisfies mutual exclusion, but not progress

20
Algorithm 2

• Shared variables
• boolean flag2 initially flag 0 flag 1
  false.
• flag i true ? Pi ready to enter its critical
  section
• Process Pi
• do
• flagi true while (flagj)
  critical section
• flag i false
• remainder section
• while (1)
• Satisfies mutual exclusion, but not progress
  requirement.

21
Algorithm 3

• Combined shared variables of algorithms 1 and 2.
• Process Pi
• do
• flag i true turn j while (flag j
  and turn j)
• critical section
• flag i false
• remainder section
• while (1)
• Meets all three requirements solves the
  critical-section problem for two processes.

22
Mutual Exclusion - Interrupt Disabling

• Process runs until requests OS service or
  interrupted
• Process disables interrupts for MUTEX
• Processor has limited ability to interleave
  programs
• Efficiency of execution may be degraded
• Multiprocessing
• disabling interrupts on one processor will not
  guarantee mutual exclusion

23
Mutual Exclusion Instructions

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

24
Test and Set Operation

• (Return original value of lock)
• boolean TestAndSet (boolean lock)
• boolean tmp lock
• lock True
• return tmp
• When calling TestAndSet(lock)
• if lock False before calling TestAndSet
• it is set to True and False is returned
• if lock True before calling TestAndSet
• it is set to True and True is returned

25
Mutual Exclusion with Test-and-Set

• Shared data boolean lock False
• Process Pi
• do
• while (TestAndSet(lock) True)
• continue // do nothing
• -- critical section --
• lock False
• -- remainder section
• while (1)

26
Exchange Instruction

• (Atomically swap two variables)
• void Swap(boolean a, boolean b)
• int temp a
• a b
• b temp
• After calling swap,
• a original value of b
• b original value of a

27
Mutual Exclusion with Swap

• Shared data (initialized to false)
• boolean lock
• boolean waitingn
• Process Pi
• do
• key True
• while (key True)
• Swap(lock,key)
• -- critical section
• lock false
• -- remainder section

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

• Disadvantages
• Busy-waiting consumes processor time
• Starvation is possible when a process leaves a
  critical section and more than one process is
  waiting. Who is next?
• 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
Intro to Semaphores

• Synchronization tool that does not require busy
  waiting
• Integer variable accessable via two indivisible
  (atomic) operations
• wait(s) s s - 1, if s lt 0 then block thread
  on the semaphore queue (wait)
• signal(s) s s 1, if s lt 0 then wake one
  sleeping process (signal).
• Each Semaphore has an associated queue.
• Can define a non-blocking version of wait(s).

31
Critical Section of n Processes

• Shared data
• semaphore mutex //initially mutex 1
• Process Pi do wait(mutex)
  critical section
• signal(mutex) remainder section
  while (1)

32
Semaphore Implementation

• Define a semaphore as a record
• typedef struct
• int value struct process L
  semaphore
• Assume two simple operations
• block suspends the process that invokes it.
• wakeup(P) resumes the execution of a blocked
  process P.

33
Implementation

• wait(S)
• S.value--
• if (S.value lt 0)
• add this process to S.L block
• signal(S)
• S.value
• if (S.value lt 0)
• remove a process P from S.L wakeup(P)

34
Some Reference Background

• Used in Initial MP implementations
• Threads are woken up in FIFO order (convoys)
• Used to provide
• Mutual exclusion (initialized to 1)
• Event-waiting (initialized to 0)
• Resource counting (initialized to number
  available)

35
Classical Problems of Synchronization

• Bounded-Buffer Problem
• Readers and Writers Problem
• Dining-Philosophers Problem

36
Bounded-Buffer Problem

• Shared datasemaphore full, empty,
  mutexInitiallyfull 0, empty n, mutex 1

37
Bounded-Buffer Problem Producer

• do
• produce an item in nextp
• wait(empty) // Decrement free cnt
• wait(mutex) // Lock buffers
• add nextp to buffer
• signal(mutex) // release buffer lock
• signal(full) // Increment item count
• while (1)

38
Bounded-Buffer Problem Consumer

• do
• wait(full) // decrement item count
• wait(mutex) // lock buffers
• remove item from buffer nextc
• signal(mutex) // release lock
• signal(empty) // increment free count
• consume item in nextc
• while (1)

39
Readers-Writers Problem

• Shared datasemaphore mutex, wrtInitiallymut
  ex 1, wrt 1, readcount 0

40
Readers-Writers Problem Writer

• wait(wrt)
• writing is performed
• signal(wrt)

41
Readers-Writers Problem Reader

• wait(mutex)
• readcount
• if (readcount 1) // First reader
• wait(wrt) // Keeps writes out
• signal(mutex)
• reading is performed
• wait(mutex)
• readcount--
• if (readcount 0) // Last reader
• signal(wrt) // Alow writer in
• signal(mutex)

42
RW Locks

• Preferred solution, writer wakes up all sleeping
  readers.
• But, this could lead to writer starvation. How
  is this fixed?
• What about when a reader wants to upgrade to an
  exclusive lock? Deadlocks?
• If pending writers, should a new reader get a
  lock?

43
Dining-Philosophers Problem

• Shared data
• semaphore chopstick5
• Initially all values are 1

44
Dining-Philosophers Problem

• Philosopher i
• do
• wait(chopsticki)
• wait(chopstick(i1) 5)
• eat
• signal(chopsticki)
• signal(chopstick(i1) 5)
• think
• while (1)

45
Potential Problems

• Incorrect use of semaphores can lead to problems
• Critical section using semaphores must keep to a
  strict protocol
• wait(S) critical section signal(S)
• Problems
• No mutual exclusion
• Reverse signal(S) critical section wait(S)
• Omit wait(S)
• Deadlock
• wait(S) critical section wait(S)
• Omit signal(S)

46
Potential Solutions

• How do we protect ourselves from these kinds of
  errors?
• Develop language constructs that can be validated
  automatically by the compiler or run-time
  environment
• Critical Regions
• Monitors

47
Critical Regions

• High-level synchronization construct
• A shared variable v of type T, is declared as
• v shared T
• Variable v accessed only inside statement
• region v when B do Swhere B is a Boolean
  expression.
• While statement S is being executed, no other
  process can access variable v.

48
Critical Regions

• Regions referring to the same shared variable
  exclude each other in time.
• When a process tries to execute the region
  statement, the Boolean expression B is evaluated.
  If B is true, statement S is executed. If B is
  false, the process is delayed until B becomes
  true and no other process is in the region
  associated with v.

49
Example Bounded Buffer

• Shared data
• struct buffer
• int pooln
• int count, in, out

50
Bounded Buffer Producer

• Producer process inserts nextp into the shared
  buffer
• region buffer when (count lt n)
• poolin nextp
• in (in1) n
• count

51
Bounded Buffer Consumer

• Consumer process removes an item from the shared
  buffer and puts it in nextc
• region buffer when (count gt 0)
• nextc poolout
• out (out1) n
• count--

52
Monitors

• High-level synchronization construct that allows
  the safe sharing of an abstract data type among
  concurrent processes.
• monitor monitor-name
• shared variable declarations
• procedure body P1 () . . .
• procedure body P2 () . . .
• procedure body Pn () . . .
• initialization code

53
Monitors

• To allow a process to wait within the monitor, a
  condition variable must be declared, as
• condition x, y
• Condition variable can only be used with the
  operations wait and signal.
• The operation
• x.wait()means that the process invoking this
  operation is suspended until another process
  invokes
• x.signal()
• The x.signal operation resumes exactly one
  suspended process. If no process is suspended,
  then the signal operation has no effect.

54
Schematic View of a Monitor
55
Monitor With Condition Variables
56
Dining Philosophers Example

• monitor dp
• enum thinking, hungry, eating state5
• condition self5
• void pickup(int i) // following slides
• void putdown(int i) // following slides
• void test(int i) // following slides
• void init()
• for (int i 0 i lt 5 i)
• statei thinking

57
Dining Philosophers

• void pickup(int i)
• statei hungry
• test(i)
• if (statei ! eating)
• selfi.wait()
• void putdown(int i)
• statei thinking
• // test left and right neighbors
• test((i4) 5)
• test((i1) 5)

58
Dining Philosophers

• void test(int i)
• if ( (state(I 4) 5 ! eating)
• (statei hungry)
• (state(i 1) 5 ! eating))
• statei eating
• selfi.signal()

59
Monitor Implementation Semaphores

• semaphore mutex // (initially 1)
• semaphore next // (initially 0)
• int next-count 0
• Each external procedure F will be replaced by
• wait(mutex) // ensures mutual exclusion
• body of F
• if (next-count gt 0)
• signal(next)
• else
• signal(mutex)Mutual exclusion within a
  monitor is ensured.

60
Monitor Implementation

• For each condition variable x, we have
• semaphore x-sem // (initially 0)
• int x-count 0
• The operation x.wait can be implemented as
• x-count // number waiting processes
• if (next-count gt 0) // if waiting in monitor
• signal(next) // wake any in monitor
• else
• signal(mutex) // wake any waiting to enter
• wait(x-sem) // wait on condition
• x-count-- // we are awake again

61
Monitor Implementation

• The operation x.signal can be implemented as
• if (x-count gt 0)
• next-count
• signal(x-sem)
• wait(next)
• next-count--

62
Monitor Implementation

• Conditional-wait construct x.wait(c)
• c integer expression evaluated when the wait
  operation is executed.
• value of c (a priority number) stored with the
  name of the process that is suspended.
• when x.signal is executed, process with smallest
  associated priority number is resumed next.
• Verifying correctness Check two conditions
• User processes must always make their calls on
  the monitor in a correct sequence.
• Must ensure that an uncooperative process does
  not ignore the mutual-exclusion gateway provided
  by the monitor, and try to access the shared
  resource directly, without using the access
  protocols.

63
Spin Locks or Simple Mutexes

• The idea is to provide a basic, HW supported
  primitive with low overhead.
• Lock held for short periods of time
• If locked, then busy-wait on the resource
• Must not give up processor! In other words, can
  not block.

64
Spin-Lock implementation
void spin_lock (spinlock_t s) while
(test_and_set (s) ! 0) while (s ! 0)
void spin_unlock (spinlock_t s) s 0
65
Blocking Locks/Mutex

• Allows threads to block
• Interface
• lock(), unlock () and trylock ()
• Consider traditional kernel locked flag
• Mutex allows for exclusive access to flag,
  solving the race condition
• flag can be protected by a spin lock.

66
Condition variables

• Associated with a predicate which is protected by
  a mutex (usually a spin lock).
• Useful for event notification
• Can wakeup one or all sleeping threads!

67
Condition Variables

• Up to 3 or more mutex are typically required
• one for the predicate
• one for the sleep queue (or CV list)
• one or more for the scheduler queue (swtch ())
• deadlock avoided by requiring a strict order

68
Implementation
Void wait (cv c, mutex_t s) lock
(cv-gtlistlock) add thread to queue unlock
(cv-gtlistlock) unlock (s) swtch () /
return gt after wakup / lock (s) return
Void do_signal (cv c) lock (cv-gtlistlock)
remove a thread from list unlock
(cv-gtlistlock) if thread, make runnable
return void do_broadcast (cv c) lock
(cv-gtlistlock) while (list is nonempty)
remove a thread make it runnable unlock
(cv-gtlistlock) return
69
Condition Variables
update predicate
wake up one thread
Thread sets event
70
Solaris 2 Synchronization

• Implements a variety of locks to support
  multitasking, multithreading (including real-time
  threads), and multiprocessing.
• Uses adaptive mutexes for efficiency when
  protecting data from short code segments.
• Uses condition variables and readers-writers
  locks when longer sections of code need access to
  data.
• Uses turnstiles to order the list of threads
  waiting to acquire either an adaptive mutex or
  reader-writer lock.

71
Windows 2000 Synchronization

• Uses interrupt masks to protect access to global
  resources on uniprocessor systems.
• Uses spinlocks on multiprocessor systems.
• Also provides dispatcher objects which are used
  by user space threads and act as either mutexes,
  semaphores or events.
• An event acts much like a condition variable.
• signaled or unsignaled state