Path: news.daimi.aau.dk!news.uni-c.dk!sunic!sunic.sunet.se!newsfeed.tip.net!news.seinf.abb.se!eua.ericsson.se!erinews.ericsson.se!cnn.exu.ericsson.se!convex!cs.utexas.edu!howland.reston.ans.net!Germany.EU.net!Dortmund.Germany.EU.net!Informatik.Uni-Dortmund.DE!veronica!warda From: warda@veronica.informatik.uni-dortmund.de (Armin M. Warda) Newsgroups: comp.lang.beta Subject: Cloning of objects Date: 9 May 1995 18:28:37 GMT Organization: CS Department, Dortmund University, Germany Lines: 92 Sender: warda@veronica (Armin M. Warda) Distribution: world Message-ID: <3ooc8l$nbc@fbi-news.informatik.uni-dortmund.de> NNTP-Posting-Host: veronica.informatik.uni-dortmund.de Keywords: clone, objects To: olm@Eng.Sun.COM (O. L. Madsen), sbrandt@daimi.aau.dk (S. Brandt), warda I realized that one big problem with Parallel/Distributed- Discrete-Event-Simulation (PDES) in Process-Interaction-Style [Fra77] a la SIMULA is the need to checkpoint and rollback processes (= coroutines in SIMULA or components in BETA), if one does not want to restrict applicable PDES-Protocols to Conservative Protocols [CM86], but wants to be able to use optimistic synchronization protocols like Time-Warp [Jef85] or the Space-Time-Simulation-Algorithm [CS89]. And I think that modelling in Event-Driven-Style (as opposed to Process-Interaction-Style) is unacceptable for modellers. Of cause it is possible to transform any simulation model written in Process-Interaction-Style to an equivalent model in Event-Driven-Style. But this seems not very elegant to me. I would prefer to have an abstract super pattern 'ParSimulation' which provides abstractions for Process-Interaction-Style (and means to specify distribution) to the modeller, like SIMULA's Class Simulation does for sequential simulation. And I would like to stay with BETA. Each process should have a method 'checkpoint' that checkpoints the total state of this process (including the execution stack of the component!) and returns a unique id. Using this id a checkpointed state could be restored by a method 'rollback'. Finally the process could be informed by a method 'cancel' that a state associated with a given id is no longer needed. (This looks a little bit like the persistent store [MIA 91-20], but of cause the state need not (should not!) be saved to secondary storage and I fear that components (resp. execution stacks) are not handled, are they? See [MIA 91-20], p.4, last paragraph.) If BETA would have a 'clone' operation -- which is currently not available (see [Mad93] p.161) -- then it would be no problem to implement an abstract super pattern 'process' with methods checkpoint, rollback and cancel. Of cause 'clone' would have to clone execution stacks of components, too. (Leave out problems arising from cloning a component with a dynamic reference, letting the component destroy the object denoted by the dynamic reference while continuing execution, an then rollback to a state where the object just destroyed is assumed to be available... Perhaps all reachable objects (transitive closure) must be checkpointed, too, a la persitent store.) I think the problem is to make the access to the execution stack of a component more flexible than the one-way fashion 'first attachment (creation), suspension, attachment, suspension,.., last attachment, termination'. This is the crucial point, isn't it? I was told that what I need would be possible in C++Sim (or at least C++Sim could be easily modified to support this), an Extension to C++ for Process-Interaction-Style simulation, which allows explicit manipulation of execution stacks, but I don't know if this is true and I would prefer to stay with BETA. [CM81] Chandy, K.; Misra, J.: Asynchronous Distributed Simulation Via a Sequence of Parallel Computations. CACM, 24(4):198-206, 1981. [CS89] Chandy, K.; Sherman, R: Space-Time and Simulation. In Proceedings of the SCS Multiconference on Distributed Simulation, 53-57, 1989. [Fra77] Franta, W. R.: The Process View of Simulation. The Computer Science Library, North-Holland, 1977. [Jef85] Jefferson, D.: Virtual Time. ACM Transactions on Programming Languages and Systems, 7(3):404-425, July 1985. [Ma93] Madsen, O. L.; Moller-Pedersen, B.; Nygaard, K.: Object-Oriented Programming in the BETA Programming Language. Addison-Wesley, 1993, ISBN 0-201-62430-3. [MIA 91-20] Mjolner Informatics: The Mjolner BETA System - Persitence in BETA, Reference Manual, Mjolner Informatics Report MIA 91-20(1.2), August 1994. A. --------------------------------------------------------------------- Armin M. Warda Universitaet Dortmund, Informatik IV, GB V, R.503, Tel: 0231-755-4824 44221 Dortmund, Privat: , Tel: 0231-75-37-30 WWW: "http://ls4-www.informatik.uni-dortmund.de/QM/MA/warda/pi.html" PGP fingerprint = 66 C0 3E 8E D9 FE 61 77 DB 37 0D 40 36 53 71 6A