Operating Systems Lecture 16

1
Operating SystemsLecture 16

• Semaphores

phones off (please)
2
Overview

• Achieving mutual exclusion
• disabling interrupts
• strict alternation
• Petersons solution
• Sleep and wakeup
• the producer-consumer problem
• Semaphores
• solving the producer-consumer problem

3
Achieving Mutual Exclusion
4
Recall the Problem

• How do we avoid potential race conditions?
• the problem is caused by two processes have free
  (simultaneous) access to a shared resource
• We need to find some way to prohibit more than
  one process from accessing such a resource
• problems only occur during shared resource access
• The part of the process which accesses a shared
  resource is termed a critical section
• only one process must be allowed to be in a
  critical section at one time this is mutual
  exclusion

5
Disabling Interrupts

• The problem seems to occur when a process is
  interrupted while accessing the shared resource
• it is a system timer interrupt that causes a
  process to be pre-empted
• So why not simply disable interrupts (and
  turn-off process switching)?
• disable interrupts just after entering the
  critical section
• re-enable interrupts just before leaving
• once in its critical section a process cannot be
  interrupted and so cannot be swapped out
• no other process can be swapped in, to mess-up
  the shared resource

6
The Danger

• Disabling interrupts is not a realistic candidate
  solution for a number of reasons
• user processes cannot be given interrupt control
  in a multi-user, multi-processing environment
• suppose someone forgets to switch them back on
• a selfish user might decide to make their whole
  program a critical section- it runs
  exclusively!
• disabling interrupts does not work in a
  multi-processor system
• the disable interrupt instruction is a low-level
  hardware feature and only affects the processor
  that executes it
• Interrupt control is the preserve of the OS kernel

7
Software Solution

• Recall that the obvious proposed solution using a
  critical_region lock flag does not work

while ( critical_region BUSY
) do_nothing critical_region BUSY ltdo
critical codegt critical_region FREE

• Perhaps this can be fixed by checking the lock
  flag a second time, just before storing it
• if ( critical_region FREE ) critical_region
  BUSY
• in fact, this doesnt help at all
• a process may still be interrupted between the
  check and set

8
Strict Alternation

• Another approach to solving the problem
• lets try making the two processes take it in
  turns to enter their critical sections
• a shared variable, turn, is initialised to zero
• each process checks turn and alters it after
  completion

9
This Works, But ...

• This solution does work
• processes must take it in turn to enter critical
  sections
• this is fine if process A reaches its critical
  section first
• Suppose, however, that process B reaches the
  critical section first
• it still has to wait until process A has finished
  its section
• so what happens if B is very fast and A very
  slow?
• B is held up for a long time!
• Even worse, no such processes can ever enter a
  critical section twice in a row
• this is not really a serious candidate for a
  solution

10
A Real Solution

• By combining the idea of lock variables with the
  idea of taking turns, the problem can be solved
• a Dutch mathematician, T. Dekker, was the first
  to solve the problem in 1965
• in 1981, G.L. Peterson discovered a simpler
  solution
• The solution needs the following variables
• each process has an integer id number
• two shared variables are needed
• turn a single flag to indicate whose turn it is
• interested array of flags to indicate whether
  each process is currently interested in entering
  (or is running) its critical region
• each process must know the others process id

11
Petersons Solution
int turn int interested2 / all values must
be initialised to zero /
12
The Solution in Action
1
0
1
1
0
0
process A
process B
process A
process A
process B
process B
process A
process A
process B
process B
process A
process A
process B
process B
process A
process A
process B
process B
process A
process A
process B
process B
process B
1
0
other 1 - process
other 1 - process
interestedprocess TRUE
interestedprocess TRUE
turn other
turn other
while ( turn other interestedother
TRUE ) do_nothing
critical code
while ( turn other interestedother
TRUE ) do_nothing
waiting to enter critical code ...
while ( turn other interestedother
TRUE ) do_nothing
critical code
interestedprocess FALSE
interestedprocess FALSE
13
Busy Waiting

• So far, all the software approaches have used
  loops of the form
• while ( some_condition ) do_nothing
• to test for some condition to come true
• Such a loop is called busy waiting
• continuously executing test wasting processor
  time
• Busy waiting can also have unexpected and
  unwelcome effects in process scheduling
• suppose the system is implementing a priority
  queue
• if the busy process is high priority, it may
  never yield from its busy waiting loop

14
Sleep and Wakeup
15
Sleep and Wakeup

• In order to get around the busy waiting problem,
  two system calls can be implemented
• sleep
• causes the caller to block until another process
  wakes it up
• wakeup
• wakes up another sleeping process
• There needs to be a method for linking a process
  calling sleep with the process calling wakeup
• either
• wakeup takes a single parameter the process id
  of the process to be woken up, or
• sleep and wakeup both take a parameter to match up

16
The Producer-Consumer Problem

• A producer is adding data to a shared buffer
• A consumer is removing data from this buffer
• how can we code this problem using sleep and
  wakeup so that the produced wont overfill the
  buffer and the consumer wont read from an empty
  buffer?

17
Another Difficulty

• But there is still a problem with this
  producer-consumer solution using sleep and
  wakeup
• Suppose the count variable is zero
• the consumer reads it and decides to go to sleep
• but before the sleep starts, the consumer is
  pre-empted
• the producer runs, enters an item into the
  buffer, increments count, and sends the consumer
  a wakeup
• the wakeup arrives at the consumer before the
  consumer starts to sleep and so will be lost
• Eventually, the producer will fill the buffer
  sleep
• both producer consumer will now sleep forever!

18
Semaphores
19
The Semaphore Primitive

• A new primitive variable type, called a
  semaphore, was introduced by E.W. Dijkstra in
  1965
• a semaphore has two operations defined
• down (a generalisation of sleep)
• checks to see if the value is greater than zero
• if so, the value is decremented
• if not, the process is put to sleep (blocks)
• up (a generalisation of wakeup)
• if there are processes waiting, then one is woken
  up
• if not, the value is incremented
• Both these are guaranteed to be an atomic action
• no other process can access the semaphore until
  the operation has completed or blocked

20
Solving Producer-Consumer

• Semaphores can be used to solve many process
  synchronisation problems
• for example, the producer-consumer problem

21
Semaphore Uses

• In the producer-consumer solution, semaphores
  have actually been used in two distinct manners
• for mutual exclusion
• the mutex semaphore is used to prevent the two
  processes reading and writing to the shared
  buffer at the same time
• it is a called a binary semaphore because it is
  only used by two processes and can only have the
  value zero or one
• for synchronisation
• the full and empty semaphores are used to
  guarantee that sequences of events do or do not
  occur in the right order
• in this case they ensure that the producer stops
  running when the buffer if full, and that the
  consumer stops running when the buffer is empty

22
Implementing Semaphores

• The key to the successful functioning of the
  semaphore is the concept of atomicity
• it has effectively been specified that the
  semaphore operation cannot be pre-empted in
  between its test instruction (e.g. if counter gt
  0) and its resulting action (e.g. sleep)
  instruction(s)
• As the semaphore is now a closely controlled
  operating system primitive (e.g. system call) it
  can safely be implemented by disabling interrupts
• an application cannot abuse the interrupt
  handling!
• But what about on multi-processor systems

23
The TSL Instruction

• Most modern processors now provide a special
  hardware instruction to implement semaphores
• commonly called the test-and-set-lock (TSL)
  instruction
• Precise implementations vary, but for example
• a processor provides TSL(memory address)
• this loads the memory contents into a register
  (e.g. the accumulator) so that it can be compared
  to e.g. zero
• at the same time the memory is set to a non-zero
  value (e.g. one)
• As the test and set are guaranteed atomic, it is
  easy to code a semaphore from a TSL instruction

24
Summary

• Achieving mutual exclusion
• disabling interrupts
• strict alternation
• Petersons solution
• Sleep and wakeup
• the producer-consumer problem
• Semaphores
• solving the producer-consumer problem