Concurrent & Distributed Systems 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 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) 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) Turnstile 1 Repeat ---- wait(s) X := Nv X := X+1 Nv := X Signal(s) ---- Until no more admissions Turnstile 2 Repeat ---- wait(s) Y := Nv Y := X+1 Nv := Y signal(s) ---- Until no more admissions Linked pair of Critical Sections