MODELING TIME AND EVENTS IN A DISTRIBUTED SYSTEM

Transcription

1 MODELING TIME AND EVENTS IN A DISTRIBUTED SYSTEM Joseph Spring School of Computing, University of Hertfordshire, College Lane, Hatfield. AL10 9AB UK herts.ac.uk 1. Distributed Systems 1.1. What is a Distibuted System? - Definitions. The Distributed Systems handout for the slides used in the lecture present various definitions that are found in the literature. Examples are taken from Coulouris, Dollimore and Kindberg (CDK), Tanenbaum and van Steen (TvS), and Silberschatz, Galvin and Gagne (SGG), [1, 3, 6]. Compare these to each other and the definition given in Leslie Lamports paper Time, Clocks and the Ordering of Events in a Distributed System Why build a Distibuted System? - Purpose. The remainder of the Distributed Systems handout presents a case (from SGG) for building a distributed system under the headings of Resource Sharing, Computational Speedup, Reliability and Communication Examples. Examples of 6 Distributed Systems are given as a handout that you should read. These are taken from CDK (first three examples), CDK (Second Edition for the ATM example) and TvS (for the last two examples) Characteristics/Challenges/Goals/Architectures/Approaches to Design in a Distibuted System. The next two sets of handouts for slides will focus upon the presentation given in CDK looking at the Characteristics of a Distributed System and the Challenges to be met in developing Distributed Systems. Question 1 Compare and contrast the three(/four) definitions discussed above. Question 2 What consequences follow from the CDK definition? Question 3 Give one example for each of the reasons given in [6] for building a distributed system. 2. The Modeling Process The modelling process is a procedure used to help us to gain a better understanding of concepts that we may be interested in. There are various presentations that one meets in the literature, the 3-stage model, the 4-stage model, the 6-stage model... and so forth. Each of these modelling procedures may be viewed as the same procedure. We are interested in: to what extent may we use the modelling process with distributed systems? what evidence exists for the use of modelling with distributed systems? how useful is such an approach with distributed systems? We note at this point that models in general are NOT correct. They do not in general tell the whole story. They are, however often found to be useful, VERY useful. 1

2 2 MODELING TIME AND EVENTS IN A DISTRIBUTED SYSTEM 2.1. The 6-Stage Modelling Process. Stage 1 What is the Problem? State the problem in a clear and unambiguous way. Stage 2 What elements have a direct/indirect bearing upon the Problem? List as many elements as possible having even remote influence upon the problem. You can always ignore possible influences until later, but it isn t alwaays so easy to come up with influences as you move through various versions of the model being constructed. Stage 3 Form a reduced list of elements to act as Properties that the model must satisfy From the very large list compiled at stage 2, extract what you consider to be the most important ones. Initially this can be a very small list, to help build a first simple working model. Stage 4 Model the Problem Here we extract the essential abstract features of the problem. Once established we move to the next stage. Stage 5 Solve the Problem Having obtained an abstract version of our problem we attempt to solve the problem Stage 6 Compare with Reality Once a solution has been obtained we consider what the model predicts for a given set of input data and compare these to those observed in the real world. If what is observed compares favourably with real world observations then we may accept the model (option A in Fig 1.). Any variations that exist between the model and reality being accepted as acceptable errors. If the model does not compare favourably with reality then we return to Stage 2 once more, reconsider the reduced set of assumptions that we used in the previous model and once a new set of assumptions are agreed run through the modelling process again (option B in Fig 1.). Figure Stage Modelling Process

3 MODELING TIME AND EVENTS IN A DISTRIBUTED SYSTEM 3 3. The Lamport Models for Ordering Events in a Distributed System 3.1. The Problem. We commence with the problem of ordering and synchronising events that occur within a distributed system [2]. For an example see figure 11.5 Events occurring at three processes on pge 445 [1]. To quote from Lamports paper, in a distribited system it is sometimes impossible to say that one of two events happened first and in response to this Lamport presents various models to assist (with varying degrees of success) in addressing this problem. We consider three of these models: the Partially Ordered Model. The Totally Ordered Model and the Anomolous Model Lamports Partially Ordered Model Assumptions. Various assumptions are made [2] for this model: A distributed system consists of a collection of distinct processes spatially seperated. Note in this asumption that Lamport states that many of the observations made apply to a single, for example multiprocessing computer. Indeed a single compuer can be viewed as a distributed system Processes communicate with each other by exchanging messages. A system is distributed if the message transmission delay is NOT negligable in comparison with the time between events in a single proces. Each process consists of a sequence of events (including sending amessage, receiving a message). Events form a sequence. A simple process is a set of events with an a priori total ordering The Happened Before Relation. This is the smallest relation such that: 1. If a, b are two vents in the same process and event a occurs before event b then a b 2. If a is the sending of a message by one process and b is the receiving of the same message by a different process then a b 3. If a b and b c then a c (Transitive Rule) This relation produces another assumption that we acknowledge, namely that for any event a, a a Two distinct events a and b are said to be concurrent if a b and b a. Question 1 Is the happened before relation a partial order on the set of events? Justify. Question 2 Does there exist an example of events satisfying the transistive rule in Fig. 1 of the paper? What of concurrent events? Question 3 To what extent do you feel this model follows a modeling process? Importance. The partial ordering is uniquely determined by the system of events. Again, in a distribited system it is sometimes impossible to say that one of two events happened first....problems often arise because people are not fully aware of this fact and its implications Limitation. The happened before relation forms an irreflexive partial ordering for the st of all events in a system. In order to distinguish between events, to order each and every event, a totally ordered model is required Role. This first model acts as a basis for (a second model as we go around the modelling process) an extension to a consistent total ordering of all events that can be implemented in a distributed system Lamports Totally Ordered Model. This model involves Logical clocks, A Clock Condition, Implementation Rules and a Totally Ordered Relation =.

4 4 MODELING TIME AND EVENTS IN A DISTRIBUTED SYSTEM Assumptions. These are the same as for the Partially Ordered Model: A distributed system consists of a collection of distinct processes spatially seperated. Note in this asumption that Lamport states that many of the observations made apply to a single, for example multiprocessing computer. Indeed a single compuer can be viewed as a distributed system Processes communicate with each other by exchanging messages. A system is distributed if the message transmission delay is NOT negligable in comparison with the time between events in a single proces. Each process consists of a sequence of events (including sending amessage, receiving a message). Events form a sequence. A simple process is a set of events with an a priori total ordering Logical Clocks. We define a clock C i for each process P i as a function assigning a number C i <a> to an event a in process P i. An entire system of clocks results for different processes P 1,P 2,P 3,... which is represented by a global clock C, a function such that to any event b in process P j the number C<b>= C j <b>is assigned. These clocks are logical NOT physical, taking for example integer values according to their position within the sequence of events to which they belong Clock Condition. For any events a and b, a b = C<a><C<b>. This condition is satisfied if: C1: If a and b are events in a process P i and a b then C i <a><c i <b> C2: If a is the sending of a message by process P i and b is the receiving of the same message by process P j then C i <a><c j <b> Implementation Rules. The implementation rules are used to ensure that the system of clocks introduced processes satisfy the clock condition. IR1: (This ensures that the clock condition C1 is satisfied) Each process P i increments the clock C i between any two successive events.. IR2: (This ensures that the clock condition C1 is satisfied) a) If event a is the sending of a message m by a process P i, then message m contains a timestamp T m = C i <a> b) Upon process P j receiving a message m it sets its clock C j greater than or equal to its current value AND greater than T m. IR1 and IR2 are said to guarantee a correct system of clocks The Relation =. Let a be an event in process P i and b an event in process P j.thena = b if and only if: a) C i <a><c j <b> or b) C i <a>= C j <b>and P i P j where denotes an arbitrary total ordering of the processes. This means that all events, may be ordered. It doesn t mean that the order is the same as that in which they actually occurred but does allow us to apply a total ordering of the events within the system under observation Importance. The model does achieve a total odering for events within a distributed system. If a b then a = b and so the relation = is an extension (or completion) of the happened before relation to the system under consideration Limitation. The relation = depends uponthe system of clocks C i and is therefore not unique. Different choices of lock lead to different implementations of the relation = Role. The totally ordered model may usefully be implemented in a distributed system. See, for example, the Mutual Exclusion Problem described in Lamports Paper [2].

5 MODELING TIME AND EVENTS IN A DISTRIBUTED SYSTEM Lamports Anomolous Behaviour Model. Anomolous behaviour is described in Lamports behaviour as the result of invoking messages external to the system under consideration. Lamport gives the example of using a telephone to go outside of the system thus allowing the possibility for lower timestamps. Two methods are outlined for this model as an extension to the previous Totally ordered model. The first is to explicitly introduce into the system the necessary informationaboutthe ordering inclding external events such as the telephone. So a timestamp T b would be issued to the receiver of the telphone call which is higher than a timestamp T a held by the instigator of the telephone call. The second approach is to introduce the Strong Clock Condition and Physical Clocks. 4. Alternative Approaches Various alternative systems exist to address the synchronisation problem discussed above. We direct the interested reader to chapter 11 [1] where discussions are held regarding Coordinated Universal Time, Cristians Method, The Berkely Algorithm and The Network Time Protocol. 5. Time, Events and the Quantum Model One might consider the synchronisation problem to be an old problem no longer of great concern, particularly as Lamports paper was published in However, the use of, for example, GPS with Einsteins relativistic and gravitation model regarding properties of space and time, together with the ever present clock drift property experienced with distributed ystems ensure synchronisation is a problem that will be with us for some time. Recent papers on the problem include [7] which employs the use of entanglement to address the synchronisation problem. Entanglement is a feature believed to be solely a quantum property [4, 5]. References [1] G. Couloris J. Dollimore, T. Kindberg. Distributed Systems, Concepts and Design. Addison Wesley, 4th Ed., [2] L. Lamport. Time, clocks, and the ordering of events in a distributed system. Communications of the ACM, 21, No. 7: , [3] A. Tanenbaum M. van Steen. Distributed Systems: Principles and Paradigms. Prentice Hall, [4] N. David Mermin. Quantum Computer Science: An Introduction. Cambridge University Press, 1st edition, [5] Michael A. Nielsen and Isaac J. Chuang. Quantum Computation and Quantum Information. CUP, Cambridge, UK, 10th anniversary edition, [6] A. Silberschatz P. B. Galvin, G. Gagne. Operating Systems Concepts. John Wiley & Sons Inc., 6th Ed., New York, [7] T. B. Bahder W. M. Golding. Clock synchronisation based on second order quantum coherence of entangled states. Seventh International Conference on Quantum Communication, Measurement and Computing, AIP Conference Proceedings, pages , 2004.