1. Concurrent & Distributed Systems Lecture 5: Semaphores and Synchronisation Concurrent processes which don’t interact in some way don’t form an interesting system – they only happen to be going on at the same time and are otherwise really quite separate. Concurrent processes can interact by sharing resources (the need for ME), or by being synchronised. If processes are synchronised, it means that the relative (logical) timing or ordering of some parts of the processes are fixed in some way. Logical time and Real time –Logical time knows about ‘now’, ‘before’ and ‘afterwards’, but the timescale is not important. All computer algorithms (and much of life) progress in this kind of time – your normal program doesn’t depend on the actual clock speed of the CPU to fulfil its logical specification. –Real Time systems have an additional timing aspect to their specifications – not only must the logical outcome of the programme be correct, but the timings of the outputs must be correct.

2. Concurrent & Distributed Systems Full and Partial Synchronisation There are systems in which all parts of the processes concerned are always synchronised. This is called full or total synchronisation. –This is like the different instruments in an orchestra, all following different staves of the same musical score, following the same timing and the same conductor all the time. –All the parts of a digital computer system synchronise themselves with the timing signal on the control bus all the time (the timings are set out in ‘timing diagrams’ relating to the control bus clock signal), so this is another example of full synchronisation. –Synchronised swimming is a sport like this too – all the swimmers do exactly the same thing at the same time! Partial synchronisation is much more common and a dominant feature of Embedded Systems. –Only some parts of the concurrent processes to have a time or ordering relationship with some parts of other processes. The rest of the time, the processes go their own way time-wise, i.e. they are asynchronous. Such systems are called partial synchronised or sometimes just ‘synchronised’.

3. Concurrent & Distributed Systems Simple one-way synchronisation One-way means that one process has to follow a time relationship set by another: –Simplest example is for just two processes: –Process A cannot do step x until process B has done step y, e.g. because A then requires information generated by B at step y. –Semaphores provide a simple synchronisation mechanism: – Initialise sem4 go to be zero Process A ---- wait(go) step x ---- Process B ---- step y signal(go) ----

4. Concurrent & Distributed Systems Two-way synchronisation: the Producer-Consumer abstraction Two-way means that both processes may have to wait for each other. There are two processes, a Producer which sends items in sequence via a buffer to a Consumer, which accepts the items from the buffer, and deals with them in some way. There are some rules: –The items must be consumed once in the order they were produced. –No items are lost –The buffer may be able to store zero items, a finite number of items, or even in principle an infinite number of items (though not in practice). Clearly the two way synchronisation implied is that the Consumer must wait for items to be placed in the buffer before it can take one out, and that the Producer must wait for there to be space in the buffer before it can put one in. Buffers are a key element of very many engineering systems ProducerConsumer

5. Concurrent & Distributed Systems The Producer-Consumer abstraction: 2 The items could be data, as in the many buffers involved in transferring data around computer systems, or signals (packets), as in communication networks, or real objects (cars, parcels, biscuits etc.) which may be passing along the various stages of some production line, or from warehouse to warehouse. Buffers allow the combined processes to operate smoothly by taking up any differences in the work rates of the producer and consumer. A classic example is the need for a large buffer to take data from a fast producer (computer CPU/memory) to a slow producer (printer). Without the buffer, the computer could only send characters at the rate which the printer mechanism could put them on the page, and would spend most of its time waiting. Another would be the supermarket warehouse, which is a buffer between the producer (lorry delivering things) which is faster than the consumer (customers buying things). On the other hand, the whole idea of modern 'just in time' (JIT) production line methods is to do with managing the producer consumer problem with very small or zero sized buffers, and so dispensing with the cost of warehouses altogether.

6. Concurrent & Distributed Systems Case 1: an infinite buffer Imagine we have a counter ‘in' for the items put in the buffer by the consumer, and ‘out' for the items taken from it by the consumer. Then we need: in and out are initially 0. The number of items in the buffer is items = in -out. So if n becomes 0, the consumer has to wait. This suggests we can use a general semaphore (which can have any value >= 0) to control both the counting of items, and the need for the consumer to wait. This is implemented as: Producer repeat produce item Buffer[in]:=item {append to buffer} in:=in+1 forever Consumer repeat wait until in > out item := Buffer[out] {take from buffer} out := out+1 forever Producer repeat produce item append to buffer signal(items) forever Items is initialised to zero Consumer repeat wait (items) take from buffer consume item forever

7. Concurrent & Distributed Systems Case 2: a finite (bounded) buffer Unlike the infinite buffer, the producer now also may have to wait, if the buffer is full, so we use another counting semaphore which becomes zero when the buffer is full to force this wait. This semaphore has therefore to count the number of free spaces in the buffer. As before the wait for the consumer will be enforced by a semaphore which counts items actually in the buffer, which will be zero when it is empty. So we now have: Mathematically, it is unnecessary to have separate counts for the number of spaces and items, since they always add up to the constant N. The reason is an engineering one, that of good use of tools, in this case semaphores. Two semaphores allow us to implement a very clear and symmetrical solution matching the symmetry of the problem. Producer repeat produce item wait (spaces) append to buffer signal (items) forever Items is initialised to zero Consumer repeat wait (items) take from buffer signal (spaces) consume item forever Spaces is initialised to N (size of buffer)

8. Concurrent & Distributed Systems A finite (bounded) buffer: 2 It may be that in addition to the synchronisation problem of the producer consumer abstraction, the ‘append’ and ‘take’ operations, or parts of them, involve common resources which cannot safely be shared. In this case there will be a need for Mutual Exclusion between the append and take operations, which can be done using a binary semaphore, as described in lecture 4: Producer repeat produce item wait (spaces) wait(fork_lift_truck) append to buffer signal (fork_lift_truck) signal (items) forever Items is initialised to zero Fork_lift_truck is initialised to 1 Consumer repeat wait (items) wait(fork_lift_truck) take from buffer signal (fork_lift_truck) signal (spaces) consume item forever Spaces is initialised to N (size of buffer)

9. Concurrent & Distributed Systems Simulation: a simple Production Line Build Case process Repeat Get raw materials Build case Wait(case_space) Put case into holding area Signal(case) Forever Build Circuit process Repeat Get raw materials Build circuit Wait(circuit_space) put circuit into holding area Signal(circuit) Forever Final assembly process Repeat Wait(case) get case from cases holding area Signal(case_space) Wait(circuit) get circuit from circuit holding area Signal(circuit_space) assemble circuit into case put assembled circuit into finished product store Forever Raw Materials Finished products Cases Holding Area Build Case Build Circuit Final assembly Circuit Holding area C C P C C P P C P Simulation Boundary