Split Queue Time Warp and a Flexible Distributed Simulation System

Transcription

1 Split Queue Time Warp and a Flexible Distributed Simulation System Helge Hagenauer and Werner Pohlmann 1. Discrete Event Simulation and its Parallelization Simulation belongs to the oldest computer applications: using a model for quasi-empirical studies is a cost-effecive and sometimes unique way of analysing a real sytem and getting a basis for decisions. A more recent purpose is to build virtual environments for training or entertainment. There is a variety of modeling approaches and computational techniques. Discrete event simulation, which is our subject here, considers the dynamics of the object system as a sequence of instantaneous state transformations called events. (Queueing systems are a classic example, with events like a job entering or leaving a queue.) In this abstraction, nothing happens between event times, so that the simulation skips the intervals. Computation time and simulated time thus become independent concepts: the computer dedicates its time and efforts to the events which, in reality, have no duration at all. This orthogonality has two important consequences. First, a computer simulation can be orders of magnitude faster or slower than the real thing; this depends on the frequency of events and their computational cost. Second, to make simulated time go on, there must always be a future event to continue with. Event processing therefore has the additional obligation to deduce subsequent events from the current state of affairs. (In a queueing example, the event of a job entering service may imply leaving it some definite time later.) Such future events are then managed in the event list (calendar, agenda,... ), a priority queue of what-when pairs ordered by time-stamps, where the foremost entry defines the current event and the current time. The principal motive of parallel and distributed simulation (PADS for short; more comprehensive presentations can be found in [11], [4] or [5]) is speed-up or, seen from a different angle, the ability to run bigger models: by subdividing a large piece of work into many small parts and having them done concurrently, side-by-side, one should get results earlier. This requires that there is enough parallizable work to outweigh the additonal effort for coordination and therefore depends on the specific example under study as well as the employed methods. A parallel/distributed simulation consists of a set of so-called logical processes (LPs), each of which represents a different part of the modelled system. There is no global state, and the LPs exclusively interact via message passing. These messages correspond to the event notices in the event list in the sequential algorithm; on the receiver side, they are put into a queue and worked off in nondecreasing timestamp order, with the head of the queue defining the local simulated time (or local virtual time, LVT) of the receiving LP. Since there are as many such queues and times as LPs, the analogy with the sequential case does not extend to the whole picture. Indeed: in the interest of speed, one must not try to keep all LPs at the same instance of time since a single moment rarely allows much concurrency. Instead, one exploits Fachbereich Scientific Computing, Universität Salzburg, Jakob-Haringer-Straße 2, A-5020 Salzburg, Austria, hagenau@cosy.sbg.ac.at, pohlmann@cosy.sbg.ac.at

2 that the causal order, i.e. the dependence of events on other events, in a model usually is much sparser than the temporal order. So the general idea is to only locally ensure that events are processed in time-stamp order. But for loosely coupled processes, this seemingly weak requirement is a problem: to process the first event from its input queue, the LP must know that it will never receive an event message with a still smaller timestamp. There are two principal methods of dealing with this difficulty, the conservative and the optimistic one (also known as time warp ): In the conservative approach, a LP waits until it has received messages from all LPs that may communicate with it; assuming that messages from the same source arrive in timestamp order, the LP can then safely process the message with minimal timestamp. This waiting rule, when applied to all LPs, is an open invitation to deadlock. There are several ways out. One possibility is the addition of socalled null messages which do not inform about events but, on the contrary, guarantee their absence until a given time; another strategy is to iteratively compute safe time windows. In the other main approach, LPs never wait for possible further messages but proceed on the basis of whatever has been received so far. This optimistic behaviour is free from deadlock, but runs the risk of getting ahead of relevant input and thus producing errors. So if and when a LP receives input that should have been considered earlier, it must rollback to a former state and cancel its unjustified interim output, thereby possibly inducing rollbacks elsewhere. Clearly, both these solutions have their drawbacks, and they can be shown to be intolerably inefficient on malicious examples. In both cases, several variants and amendments have been proposed and studied. Both methods can be shown to be correct (i.e. to make progress) in a rather direct way, but there is a mathematically more involved and more instructive alternative (cf.[12]): The LPs that make up a parallel/distributed simulation produce virtually infinite streams of event/time messages from input streams of the same type so that the overall task of the simulation appears as a fixed point problem in a somewhat unusual domain. Under reasonable restrictions (like that events are nowhere dense on the time axis) the domain of streams of event/time information can be seen to bear two classical mathematical structures with notions of convergence, which nicely correspond to the two fundamental PADS algorithms. Metric convergence and Banach s fixed point theorem lead to the optimistic variant (indeed, a classic relaxation approach), and convergence in the sense of complete partial orders and Kleene s fixed point theorem leads to the conservative variant (with its characteristic monotonicity). In both cases, the standard iteration of the fixed point theorems is replaced by its asynchronous or chaotic variant as described in [1] and [3] for the parallel/distributed solution of numerical and other problems. 2. Split Queue Time Warp Considering LPs as stream processing functions, we of course mean computable (programmed) functions that produce finite initial parts of their output stream from finite initial parts of their input streams. The exact relationship between those two how much output for how much input is relevant and depends on properties of the modelled system as well as on how these are reflected in the actual programming. An example is the classic requirement in conservative PADS that a model, and then its LP programs, must possess lookahead : an LP having read messages up to time t (i.e. LVT is t) will henceforth only produce messages with timestamp greater or equal t + d for some 2

3 positive constant d. Reversing the perspective, one can ask whether a LP has needed all its hitherto consumed input to produce its actual outward behaviour. Or whether additional past input would have led to additional output messages or even changed/canceled actual output. Clearly, this type of question is relevant for the optimistic method, where rollbacks and especially cascades of them form a major cost and should be avoided. In Salzburg, we studied the latter of these questions and used it for a generalisation of time warp. In standard time warp, henceforth called TW, LPs are programmed to process incoming event messages in strict timestamp order. This strategy is safe but possibly overcautious since a temporally next message may be completely irrelevant for the next move of the receiving LP. A typical case is synchronisation of model elements. Example: consider taxi-cabs and customers arriving at a taxi stand (see figure 1). If there already is a customer present, the next output of the taxi-stand LP depends on the availability of a free taxi and not on the arrival of more customers. Consequently, in this state, the LP may ignore incoming messages that denote customer arrivals and instead look for a message that denotes a returning taxi. (Note that in this situation, processing a customer messsage would just copy the information into some internal data structure.) Figure 1. Taxi stand example: TW strategy causes superfluous rollback Such state-dependent postponement of message consumption is beneficial because in a time-warp context incoming messages may be poisoned, i.e. still out of order (because other LPs or messages lag behind) or even incorrect, and may thus cause a rollback. Split Queue Time Warp, SQTW, [7], 3

4 avoids the superfluous rollback by making message reception lazy or by need. To this end, a LP may own several input queues instead of one, and different queues correspond to different message types so that waiting for a certain kind of message is possible (see figure 2). The basic no-wait/errorrecovery approach of time warp can be generalised to work with the new arrangement; the need for rollbacks is now discovered by comparing changes in the input queues against how far the respective queues were already read. I.e. the past of a LP is now delimited by a vector of temporal values (each of which give the timestamp of the most recently read message of the respective queue), whereas its future (where its own messages are sent) is defined by the maximum of these values. Or, to put it differently, we now have a local form of asynchrony in addition to the asynchrony across the LPs. Figure 2. Taxi stand example: SQTW strategy without rollback 3. A Flexible Simulation System We implemented prototypes of SQTW in Ada 95 and in Java. Experiments showed that SQTW can indeed reduce the number of rollbacks and thus outperform TW on suitable examples. Assured by these experiences, we built a completely new framework that allows to apply different discrete event simulation algorithms to the same software realisation of a simulation model. Clearly, TW is a specialisation of SQTW, and we can execute a model programmed for SQTW by TW as well - by merging the different queues into one and simplifying some things in the background. But not the other way round, because a SQTW LP must make state-depending choices of the type of input message it wants next! Furthermore, we wanted to include classic sequential (event-list) simulation, for validation of models or because it can be preferable in some contexts. 4

5 Our new design, in its present state, offers TW, SQTW and sequential simulation; other posibilities will be considered in future. The architecture strongly relies on object oriented techniques and, especially, design patterns ([6]). We use Java as implementation language, but possibly will produce an Ada version as well as soon as the next revision of the language expands its OO support (esp.provide an equivalent of Java s interface construct). In our framework, we assume LPs of small granularity so that many LPs are mapped to the same computer. Consequently, they are grouped into submodels each of which is directed by a submodel-manager which, as a parameter, gets a strategy for scheduling its LPs. To facilitate this scheduling, our LPs are not threads but objects that offer a single-step method to be called iteratively from outside, by the submodel-manager. As regards the separation of simulation methods and model definitions, we achieve the sought-for flexibility by the introduction of two class hierarchies (cf. the bridge pattern in [6]). The first hierarchy (let us use the term LP for its elements) defines types that provide the communication and simulation machinery (but nothing descriptive), and the second hierarchy is for model-specific information, i.e. describes the parts of the sytem under study. Let us use the term model entity, or ME, for this second family of classes. As indicated above, different simulation mechanisms (LP classes) have different demands on what they must know about the model entity (ME) they run: a rollbackable LP e.g. must be able to save (part of) ME state for possible rollbacks. We therefore add a third hierarchy of adapter classes that define suitably enriched interfaces of MEs. Like MEs, concrete adapters are modeler s responsibility, and they must be defined in close relation to the ME in question. It is tempting to place a maximal interface into the root class of the ME hierarchy and give trivial semantics to its methods, but further addition of supported simulation mechanisms might contradict this supposed maximality. On the other hand, the content of adapters could be appended to LPs in a further subclassing step; but we think that combination rather than subclassing gives complete flexibility (adapter and LP class hierarchies will not be exactly parallel) without danger of confounding different concerns. Figure 3 contains a sketch of the class diagram; we comment on some main points: MEs look like traditional event-oriented simulators; they comprise a state and some statetransforming operations. These operations are triggered by the receipt of messages, and the modeler has the obligation to implement an execute method for every type of message that may be sent to the ME. As regards the choice of the appropriate operation: we use the Command Pattern ([6], [10]) for message communication, and the action to be bound to a message depends on both the specific message type and the receiver type, i.e. we use double dispatch. In defining operations, the modeller can use a send_message method that is inherited from abstract_model_entity and implemented there by delegation to the associated LP (which contains the ultimate implementation of send_message via invoking receive_message on the destination LP and saving a copy for rollbacks). The LP hierarchy starts with an abstraction split into two levels to mark the difference between receive_message, which is called remotely by other LPs, and do_step and send_message, which are called only locally by the submodel manager respectively the associated ME. These three operations make up the LP interface (apart from installation methods which we do not discuss here); the following levels of the class hierarchy are for implementation only. In the SQTW case, the main attributes are a mailbox for incoming messages (a monitor object to deal with concurrent calls on receive_message), a state stack for rollbacks and an output buffer to remember sent messages for the same purpose. do_step is broken down into 5

6 Figure 3. Class structure 1. read messages from mailbox and sort them into appropriate queues, using the help of the associated adapter, 2. check consistency which leads to either rollback or state-saving, 3. execute next message(delegate to adapter/me for for selection). Adapters have to provide LPs with means of placing incoming messages into queues (one in TW, several in SQTW) and choosing the next-to-be-processed message (by timestamp in TW or other, e.g. state and type considerations in SQTW). They additionally implement the memento pattern to let the LP save/restore the relevant part of ME s mutable state for rollbacks. 6

7 References [1] D. Bertsekas and J. Tsitsiklis, Paralleland Distributed Computation: Numerical Methods, Englewood Cliffs, Prentice Hall, [2] A. Burns and A. Wellings, Concurrency in Ada. Cambridge University Press, New York, [3] K. N. Chandy and J. Misra, Parallel Program Design. Addison-Wesley, Reading, Ma., [4] A. Ferscha,. Parallel and Distributed Simulation of Discrete Event Systems, Parallel and Distributed Computing Handbook (A.Y. Zomaya ed.), Mc Graw-Hill, [5] R. M. Fujimoto,. Parallel and Distributed Discrete Event Simulation, Wiley, New York, [6] E. Gamma, R. Helm, R. Johnson and J. Vlissides, Design Patterns Elements of Reusable Object-Oriented Software, Addison Wesley, [7] H. Hagenauer and W. Pohlmann, Making Asynchronous Simulation More Asynchronous, Proc. 10th European Simulation Conference, Budapest, [8] H. Hagenauer and W. Pohlmann, Ada 95 for a Distributed Simulation System, Proc. Conference Reliable Sortware Technologies - Ada-Europe 98 (Lars Asplund ed.), Uppsala, Lecture Notes in Computer Science 1411, Springer, [9] D. R. Jefferson, Virtual Time, ACM TOPLAS, 7, pp , [10] B. Meyer, Object-Oriented Software Construction, Prentice Hall, [11] J. Misra, Distributed Discrete Event Simulation, ACM Computing Surveys, 18(1), p.39-65, [12] W. Pohlmann, A Fixed Point Approach to Parallel Discrete Event Simulation, acta informatica 28, p ,