Semaphores

1
Semaphores

• Explain the following terms
• pre-emptive scheduling
• non-pre-emptive scheduling
• Explain the disadvantages of using Test Set
• Outline the behaviour of semaphores
• Use semaphores to solve concurrency problems

2
Scheduling

• Scheduling
• Deciding which thread to execute
• Non-preemptive Scheduling
• Executing task must volunteer to give up
• By requesting input or output
• By explicitly yielding control
• Preemptive Scheduling
• Scheduler can forcibly suspend the running task
• When a high priority task becomes ready
• When a time-slice completes

3
TEST and SET

• Hardware Instruction
• Sets a variable to 1 returns previous value
• In a single atomic operation
• Use
• Initialise flag to 0 before starting other
  threads
• Keep trying to get control of the critical region
• do
• busy testset(flag)
• while (busy 1)
• // Only you are in the critical region
• // perform critical operations
• flag 0 // reset must be atomic

4
Program Mutex with Test Set

• Example in Java-like pseudocode

• class P1 extends Thread
• public void run()
• int loc1
• while (!finished())
• do
• loc1 TestSet(val,1)
• while (loc1 1)
• criticalRegionWork()
• set(val, 0)
• otherWork()

• class P2 extends Thread
• public void run()
• int loc1
• while (!finished())
• do
• loc1 TestSet(val,1)
• while (loc1 1)
• criticalRegionWork2()
• set(val, 0)
• otherWork2()

5
Main Program

• // declarations of P1 and P2
• class notReallyJava
• static int val 0
• public void main()
• P1 thread1 new P1()
• P2 thread2 new P2()
• thread1.start()
• thread2.start()

6
Problems with Test and Set

• Busy-waiting
• The threads constantly check the value
• Inefficient
• Disastrous with non-pre-emptive scheduling
• Is there a problem with priorities?
• Low-level
• Little support for concurrent programming
• Hard to use to solve common problems
• Easy to make mistakes

7
Semaphore

• A higher level synchronisation primitive
• Keeps an integer count that is gt 0
• Operators wait signal
• signal( sem ) java sem.release()
• increment value or resume a waiting thread
• wait( sem ) java sem.acquire
• if sem gt 0 decrement value,
• otherwise suspend current thread until value gt 0
• Operators are atomic
• Only one thread at a time can be executing one

Dijkstra V(sem)
Dijkstra P(sem)
8
Semaphore Invariant

• Semaphore value
• I initial value
• nS number of signals
• nW number of completed waits
• val(sem) I(sem) nS(sem) - nW(sem)
• Invariant
• Since val(sem) ? 0 by definition,
• The following is an invariant for any semaphore
• nW(sem) ? I(sem) nS(sem)
• You cant take out more than have been put in

val
val
I
nS
nW
9
Mutual Exclusion with Semaphores
Mutual exclusion Ensuring no more than one
thread in a critical region
Critical region Sections of code that could
suffer concurrent problems

• P1
• wait( sem )
• critical region
• signal( sem )
• rest of actions

• P2
• wait( sem )
• critical region
• signal( sem )
• other stuff

What should be the initial value of the semaphore?
10
Proof of Mutual Exclusion

• sem is initially 1
• nW(sem) number of completed waits
• Providing access to critical region is
• Wait before, Signal afterwards
• Number in region is N nW(sem)-sS(sem)
• From the invariant
• nW(sem) ? nS(sem) 1
• nW(sem)-nS(sem) ? 1
• N nW(sem)-nS(sem) ? 1
• At most 1 thread can be in the critical region

11
Simple Synchronisation

• One thread held until another does something
• Semaphore proceed is initially 0

• P1
• Do something
• Wait(proceed)
• Do action relying on P2

P2 Do preparation Signal(proceed) Do something
else
12
Semaphore Weaknesses

• Cannot conditionally enter or leave a WAIT
• E.g. cannot wait with a timeout
• Cannot examine the value of the semaphore
• without executing a WAIT and becoming vulnerable
  to being blocked

13
Producer/Consumer Problem
P1
C1
Buffer (size N)
P2
C2
Pn
Cn

• Items deposited and extracted from buffer
• Concurrency Problems
• Mutual Exclusion
• Buffer must be protected from simultaneous access
• Synchronisation
• Producers cannot insert into full buffer
• Consumers cannot extract from empty buffer
• 0 ? Number deposited Number extracted ? N

14
Producer/Consumer Basic Threads

• Algorithms without synchronisation

Consumer Repeat extract item from
buffer consume item forever
Producer Repeat produce item deposit item in
buffer forever
15
P/C Mutual Exclusion

• How to ensure mutual exclusion?

• Initialise mutex to ?

• Initialise mutex to 1

• Use semaphore avail to record number of items
  stored

• Use semaphore free to record number of free
  buffer slots

Producer Repeat produce item deposit
item in buffer forever
Consumer Repeat extract item from
buffer consume item forever
Wait for new item
Wait for free slot
Signal availability of item
Signal availability of slot
16
P/C Controlling Resources

• How to ensure mutual exclusion?

• Initialise mutex to 1

• Initialise avail to ?

• Initialise avail to 0

• Initialise free to ?

• Initialise free to N

Producer Repeat produce item put item
in buffer forever
Consumer Repeat take item from buffer consume
item forever
Wait(avail)
Wait(free)
Wait(mutex)
Wait(mutex)
Signal(mutex)
Signal(avail)
Signal(free)
Signal(mutex)
17
What can we prove?

• At most one thread in the critical region?
• The same proof as before will work here

18
What can we prove?

• Contraints on number of items in buffer
• 0 ? Number of items in buffer (B) ? N
• B insertions extractions I - E
• From producer
• nS(avail) ? insertions ? nW(free) (Why)
• From consumer
• nS(free) ? extraction ? nW(avail)
• -nW(avail) ? -extraction ? -nS(free)
• nS(avail)-nW(avail) ? I - E ? nW(free)-nS(free)
• Now use invariants on the semaphores

19
Number of items in buffer

• Invariants
• nW(free) ? nS(free)N
• nW(free) - nS(free) ? N
• nW(avail) ? nS(avail)
• 0 ? nW(avail) - nS(avail)
• nS(avail)-nW(avail) ? I - E ? nW(free)-nS(free)
• 0 ? I - E ? N

20
Evaluating the proof

• Was it easy to create?
• Was it easy to understand?
• Was it convincing?
• Can we check the logic?
• Can you show the result more simply?
• Are you sure of your argument
• Remember these are concurrent programs
• Many possible paths
• Argument must hold for every possible path
• Proof holds for all paths

21
P/C Mutual Exclusion

• Does this work?

• Initialise mutex to 1

• Initialise avail to 0

• Initialise free to N

Producer Repeat produce item put item
in buffer forever
Consumer Repeat take item from buffer consume
item forever
Wait(mutex)
Wait(mutex)
Wait(avail)
Wait(free)
Signal(mutex)
Signal(avail)
Signal(free)
Signal(mutex)
22
Evaluating the proof

• Our proof would still work for this program
• So, it wasnt a complete correctness proof
• Concurrent programs are difficult to reason about
• The proof guaranteed some desirable features
• Doesnt guarantee correctness
• Also need to guarantee deadlock cant occur

23
Summary

• Test Set
• Could be used for synchronisation
• But hard to use
• Uses busy waiting
• Could be used on multi-processor system
• Semaphore
• Non-negative count
• Signal Wait
• Wait suspends if count is zero
• Can be used to solve many concurrency problems
• Higher level, more efficient