Transcript Lecture 7: Critical review of semaphores

Lecture 7: Critical review of semaphores
•
•
•
Sem4’s are very powerful system programmers tools, provided by operating systems.
They can be used (as binary sem4 pairs) to provide mutual exclusion where
processes share critical sections (i.e. parts of two or more processes which need to
access some shared resource which can only safely be used by one process at a
time). This is possible where lots of processes share lots of resources, in which case
a separate binary sem4 is needed for mutual exclusion on each resource. But the
sem4’s are applied to each set of critical regions separately – so the programmer has
to know what s/he is doing, to apply all the wait()..signal() pairs correctly and to check
that they are correct. The sem4’s don’t ‘know’ anything about the overall system
design, so it is quite possible to create situations such as deadlock .
Sem4’s rely on the system programmer’s knowledge to apply them correctly – there
are no compiler or system tools to check that all the waits and signals are in the right
places and initialised correctly (though a bit of this is possible in real time operating
systems such as InTime – see the final year Real Time & Embedded Systems unit)
Lecture 7: Critical review of semaphores
•
•
Annotation of a simple programming error – the wait and signal operations in process
2 have been put the wrong way round. s is correctly initialised to 1.
Process 1
--------------wait(s)
critical section 1
use resource s
signal(s)
-------What happens?
–
–
–
Linked pair of
critical
sections
Process 2
-----signal(s)
critical section 2
use resource s
wait(s)
-------------
The critical sections are no longer mutually exclusive, a potentially disastrous safety problem.
You should work through some scenarios in your logbook to see what might happen.
The processes are asynchronous, so it may never happen that the two get into their critical
sections at the same time (but they could).
So the system might operate for a long time (even forever) without the unsafe scenario ever
showing up. In engineering these are called intermittent or hidden faults. They are the worst
possible kind of fault because they are difficult to detect