1. Concurrent & Distributed Systems Lecture 10: Monitors What? –First of all, what NOT! The term ’monitor’ was used in the past for the mini operating system (usually stored on an EPROM) which came on single board computers when micro-processing first started out in the 1980’s. An example was SWTBUG used in Motorola’s rival to the first Intel Systems. Bill Gates started out here too. These days we would call such a thing a ‘kernal’. –The Monitors we are dealing with are modern tools for concurrency. –They were the pre-cursors of Object Oriented Programming (now an essential Software Engineering tool Why? –To carry the encapsulation principle (Critical Regions have this for data only) as far as possible, to achieve all the quality benefits that encapsulation brings.

2. Concurrent & Distributed Systems Lecture 10: Monitors: How? How do Monitors work –First of all a general picture: –Notes: In a Pascal style annotation, Syntax might look like: Monitor x Data declarations procedure1 procedure2 … Initialisation End x Basis of concurrency control in MODULA 2 Also in ADA, MESA, Turing Plus Origins C.Hoare (Oxford) B. Hansen (Harvard, USA) Local data Procedures Initialisation code Only for Monitor’s own local data Monitor needs to be set up in a known state Totally protected from things going on in the rest of the software system To implement the functions provided by the Monitor

3. Concurrent & Distributed Systems Lecture 10: Monitors: What? –Compared with OOP, Monitors lack inheritance and the idea of classes. Tis is because of its origins as a concurrent quality and safety tool. Both the things above are to do with software productivity, which is a more modern concern. –Monitor operation, the rules: Monitors themselves have global scope. Concurrent application processes can call the procedures of the Monitor to access the Monitor’s data. Monitor data cannot be accessed in any other way – ie there is very strong encapsulation. Only one Monitor procedure at a time can access the data (the compiler for the Monitors language has to ensure this somehow – but that is the compiler writers problem – applications programmers see the Monitor simply as a tool which obeys the rules. –This ensures mutually exclusive access to the data –So Monitors will have have potential queues of processes which might be trying to access the data (via one of the Monitor procedures, of course) when this is not possible

4. Concurrent & Distributed Systems Lecture 10: Monitors: an example –Example: How to use Monitors to achieve mutual exclusion. The basic idea is simple – turn all the critical sections in the different processes into procedures inside the monitor – then they will automatically be mutually exclusive. –So would be implemented by a monitor and simply used as below: Process P1 ---- wait(s) operations x, y, z Signal(s) ---- Process P2 ---- wait(s) operations p, q, r Signal(s) ---- Local data Proc A x, y, z code Procedures Initialisation code Proc B p, q, r code ME1 Process P1 ---- ME1.A ---- Process P1 ---- ME1.B ----

5. Concurrent & Distributed Systems Lecture 10: Monitors: Condition Variables 1 –As for critical regions, encapsulation leads to the need for conditional entry to the monitor. This is done by –Condition Variables There are two possible operations on a Condition Variable There are two different syntaxes for these. Most common syntax is cwait(x) and csignal(x), where x is the Condition Variable Note – these are not the same as the wait and signal operations on a semaphore!! x is not a semaphore. x is not even a variable (despite being called a Condition Variable). x is just a ‘tag’ or a ‘label’, whose only purpose is to allow us to link the right cwait to the right csignal, when there are lots of them. Another syntax is delay(x) or suspend(x) and resume(x)

6. Concurrent & Distributed Systems Lecture 10: Monitors: Condition Variables 2 –How do Condition Variables work? –cwait(x) puts the calling procedure (one of the procedures in the monitor) to sleep. This removes mutually access to the monitor and so allows other monitor procedures to start work. –This continues until another monitor procedure executes a csignal(x), when mutual exclusion is re-established. Note – you can now see why we need the tag ‘x’ to make sure that the csignal refers to the correct cwait. –If a csignal(x) is executed and there is no procedure asleep on a corresponding cwait(x), then it is just ignored.

7. Concurrent & Distributed Systems Lecture 10: Monitors: Condition Variables 3 –Problem! Q says cwait(x) then later, P says csignal(x) –After the csignal, we must have mutual exclusion, so which procedure continues P or Q? This is a question of Monitor design – it has to be one way or the other, P or Q, and leads to two different versions of monitors. Charles Hoare’s version says Q continues so P waits until Q leaves the monitor, or until Q sleeps again. - easier to implement - most common B. Hansen’s version says P continues. - Q will now resume later and the condition may be out of date! Local data Proc Q ----- cwait(x) ----- Procedures Initialisation code Proc P ---- csignal(x) ----