Transcript Lecture 4

Lecture 4: ME solutions
•
Lecture 3 considered possible algorithms for achieving Mutual Exclusion
between the critical sections of processes sharing a resource. None of the
algorithms were ideal (i.e. both safe, live and efficient).
•
This lecture explains one example of an algorithm which is both safe and live
(Dekkar’s algorithm). There are some others as well.
•
The lecture also shows why new engineering tools, new computer hardware
even, is needed to make real progress in the problems of concurrent processes.
•
The first new tool is the semaphore
Concurrent & Distributed Systems
Dekkar’s algorithm
•
This is based on the safe version of the two keys algorithm (CCP6a)
Process 1
--------P1:= inCritical
while P2 = inCritical do
Begin {Dekkar's modification to the busy waiting}
If turnToGo = 2 then Begin {P1 gives way by pretending}
P1 := outOfCritical;
While turnToGo = 2 do; {wait for P2 to exit CS}
P1 := inCritical;
End;
End; {of Dekkar's modification}
{critical section here}
•
•
turnToGo := 2;
P1 := outOfCritical
----------Process 2 has the opposite logic, turnToGo can be initialised to either process
Dekkar’s algorithm can be proved safe and live – this is the hard bit!
Concurrent & Distributed Systems
Dekkar’s algorithm: 2
•
Dekkar’s algorithm was proved safe and live
– Applies to 2 processes, in the version shown
– Has quite complex pre-protocol
• Hence requires very close Quality Control (QA)
– Can be extended to > 2 processes, but then
• Protocols much more complicated
• QA gets even worse
– Still involves processes in ‘busy waiting’ loops
•
Other algorithms have been invented
– Eg Peterson’s algorithm, ‘bolt’ algorithms
– All quite complex and difficult
•
Lots of other research done, identifying
– Need for atomic ‘test_and_set’ operations, or
– Atomic exchange operations eg x:=:y
Concurrent & Distributed Systems
Semaphores: Design Philosophy
•
•
•
•
•
Existing methods not good (not even Dekkar’s algorithm)
However the problem is very well understood (not having atomic operations
such as test_and_set, or exchange operations)
Engineering solution
– Specify new tools in terms of abstract functionality (we know what we want)
– Persuade someone to sort out the problems of implementing them
• Hardware manufactures, chip designers
– Modern CPUs do have ‘test and set’ and ‘exchange’ instructions
• Software designers, i.e. Operating Systems designers
Concurrent & Distributed Systems are so important that many such modern
tools now exist.
The first, and still very important (still underpins lots of concurrency in Unix,
Linux etc) was the Semaphore.
– Named after the first systems of digital communication (~300 years ago)
Concurrent & Distributed Systems
Semaphores: The abstraction
•
A semaphore is a protected integer system entity with special attributes:
– Sem4’s have an identifier
– Concurrent systems can employ many sem4’s (with different identifiers)
– Sem4’s are globally accessible by concurrent processes needing to use
them (this means that in practice the processes need access to the same
memory address space – so sem4’s are not really for distributed systems,
where other equivalent tools will be needed.
– Access to sem4’s by processes is atomic (cannot be interleaved or
interfered with by other processes using the same sem4).
– Each Sem4 has a queue of waiting processes (which could be empty).
•
Processes can only use sem4’s via three ‘system calls’
– Access to these system calls may be limited to ‘protected code’ coming
from system programmers etc (cf accessor methods in Java and the
philosophy of encapsulation/object oriented programming/agents etc)
Semaphores can be binary (boolean) sem4’s (whose value can only ever be 0
or 1) or counting (general) sem4’s (can have any +ve value)
Semaphores come in ‘Strong’ and ‘Weak’ varieties, defined by the type of their
associated queues,
•
•
Concurrent & Distributed Systems
Semaphore system calls
•
•
•
•
•
Processes can use a sem4 ‘tool’ by using one of three system calls. The action
of each call is atomic and must be implemented to follow exactly the definitions
below:
Initialise(s,x)
– Creates a new sem4 with s as its identifier and x as its initial value
Wait(s)
– If s = 0 then the calling process is added to the sem4’s queue of waiting
processes (sem4 calls are part of the operating system kernel, so while
processes are in a sem4 queue, they do not get time from the scheduler
– so no ‘busy waiting’ losses.
– Id s > 0 then the calling process continues executing and s:=s-1.
Signal(s)
– If there is one or more processes in the sem4’s queue of waiting processes,
then one of them * is ‘woken up’, ie the scheduler will give it time again and
the process can continue.
– If not, the calling process continues and s:=s+1
* which one – this depends on what kind of queue
– Strong sem4’s have FIFO queues, Weak sem4’s have other kinds (eg
priority based) of queues - with advantages and disadvantages.
Concurrent & Distributed Systems
Mutual Exclusion by using Sem4’s :1 (CCP7)
•
•
Sem4’s can be used to make Critical Sections Mutually Exclusive
Initialise the sem4 to 0 eg initialise (s,1)
Turnstile 1
Turnstile 2
Repeat
Repeat
----
----
----
----
wait(s)
X := Nv
X := X+1
Nv := X
Signal(s)
---Until no more admissions
•
•
•
wait(s)
Linked pair
of Critical
Sections
Y := Nv
Y := X+1
Nv := Y
signal(s)
---Until no more admissions
Safe. Live (actions are atomic, so no interleaving problems), but must be used
properly.
Can be applied to a Critical Section shared by any number of processes
Can ‘look after’ any number of shared resources (one sem4 for each)
Concurrent & Distributed Systems