1 / 32

Formal Model for Simulations

VIETNAM NATIONAL UNIVERSITY UNIVERSITY OF ENGINEERING AND TECHNOLOGY. Formal Model for Simulations. Instructor: DR. Le Anh Ngoc Subject: INT 6005 3 Presented by – Group 6: 1. Nguyen Son Hung 2. Le Van Hung 3. Nguyen Xuan Hau 4. Nguyen Xuan Tung. AGENDA. Introduction

nhi
Download Presentation

Formal Model for Simulations

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. VIETNAM NATIONAL UNIVERSITY UNIVERSITY OF ENGINEERING AND TECHNOLOGY Formal Model for Simulations Instructor: DR. Le Anh Ngoc Subject: INT 6005 3 Presented by – Group 6: 1. Nguyen Son Hung 2. Le Van Hung 3. Nguyen Xuan Hau 4. Nguyen Xuan Tung

  2. AGENDA • Introduction • Problem Specifications • Communication Systems • Modeling Process • Admissibility • Simulations • Pseudocode Conventions • Conclusion • References

  3. Introduction Motivation • There are so many way to be solved specifying a problem in DS that we approach about system simulations and algorithms insteading of looking inside an algorithm. • It is focused on the interface between the device's algorithm or processor with the outside world.

  4. Introdution

  5. Techniques applied • Layering is the technique that allows system designers to control the complexity of building large-scale systems • Specification sub-system P as a set of inputs in(P), a set of outputs out(P), and a set of allowable sequences seq(P) of inputs and outputs:

  6. Problem Specifications Problem specification when put conditions (sequence, time,...) on processor states as they relate to each other and to initial states.

  7. Problem Specifications Mutual Exclusion Example • inputs: • T0, …, Tn-1 • Ti indicates pi wants to try to enter the critical section • E0,…, En-1 • Eiindicates pi wants to exit the critical section • outputs: • C0,…,Cn-1 • Ci indicates pi may now enter the critical section • Ri,…,Rn-1 • Ri indicates pi may now enter the remainder section

  8. Problem Specifications Mutual Exclusion Example • a sequence  of inputs and outputs is allowable iff, for each i, •  | i cycles through Ti, Ci, Ei, Ri • each proc cycles through trying, critical, exit, and remainder sections in that order • whenever Ci occurs, most recent preceding input or output for any j ≠ i is not Cj • only one process is in the critical section at a time

  9. Problem Specifications Mutual Exclusion Example: allowable p1 T1 R1 T2 Mutual Exclusion T0 C2 C0 p2 E2 p0 E0 R2 T0 T1C0 T2 E0C2 R1 E2 R2 …

  10. Problem Specifications Mutual Exclusion Example: not allowable p1 T1 T2 Mutual Exclusion T0 C2 C2 C0 p2 p0 E0 T0 T1 C0 T2C2… E0C2 …

  11. Communication Systems So Far Set 14: Simulations • So far, we have explicitly modeled the communication system • Inbufand outbuf state components and deliver events for message passing, • explicit shared variables as part of configurations for shared memory • Not so convenient when we want to study how to provide one kind of communication in software, given another kind.

  12. Different Kinds of Communication Systems Set 14: Simulations • Message passing vs. shared memory • different interfaces (sends/receives vs. invocations/responses) • Within message passing: • different levels of reliability, ordering • different guarantees on content (when malicious failures are possible) • Within shared memory: • different shared variable semantics

  13. What Kinds of Simulations? Set 14: Simulations How to provide broadcast (with different reliability and ordering guarantees) on top of point-to-point message passing How to provide shared objects on top of message passing How to provide one kind of shared objects on top of another kind How to provide stronger synchrony on top of an asynchronous system How to provide better-behaved faulty processors on top of worse-behaved ones

  14. New Way to Model Communication Systems Set 14: Simulations • Interpose a communication system between the processors • A particular type of communication system is specified using the approach just described • focus on the desired behavior of the communication system, as observed at its interface, instead of the details of how that behavior is provided

  15. Asynchronous Point-to-Point Message Passing Example Set 14: Simulations Interface is: • inputs: sendi(M) • models pisending set of msgsM • each msg indicates sender and recipient (must be consistent with assumed topology) • outputs: recvi(M) • models pi receiving set of msgsM • each msg in M must have pi as its recipient

  16. Asynch MP Example (cont'd) Set 14: Simulations • For a sequence of inputs and outputs (sends and receives) to be allowable, there must exist a mapping  from the msgs in recv events to msgs in send events s.t. • each msg in a recv event is mapped to a msg in a preceding send event •  is well-defined: every msg received was previously sent (no corruption or spurious msgs) •  is one-to-one: no duplicates •  is onto: every msg sent is received

  17. Asynchronous Broadcast Example Set 14: Simulations • Inputs: bc-sendi(m) • an input to the broadcast service • pi wants to use the broadcast service to send m to all the procs • Outputs:bc-recvi(m,j) • an output of the broadcast service • broadcast service is delivering msgm, sent by pj, to pi

  18. AsynchBcast Example (cont'd) Set 14: Simulations • A sequence of inputs and outputs (bc-sends and bc-recvs) is allowableiff there exists a mapping  from each bc-recvi(m,j) event to an earlier bc-sendj(m) event s.t. •  is well-defined: every msgbc-recv'ed was previously bc-sent •  restricted to bc-recvi events, for each i, is one-to-one: no msg is bc-recv'ed more than once at any single proc. •  restricted to bc-recvi events, for each i, is onto: every msgbc-sent is received at every proc.

  19. Modeling Process proposed facility Set 14: Simulations • May be several algorithms (processes) runs on each processor to simulate the desired communication system. • For example, a processor run two algorithms (processes) at the same time • one process (algorithm) that uses the broadcast service • another process (algorithm) that implements the asynchronous broadcast system on top of the asynchronous point-to-point message-passing system

  20. Modeling Process (Cont.) Algorithm composition • Ordering of process, forming a “Stack of protocols” • Environment communicates with the top layer • Each process uses communication primitives to interact with the layer beneath it • The bottom layer communicates with the Communication System Set 14: Simulations

  21. modeled as a problem spec (interface & allowable sequences) layer 1 layer 2 layer 3 communicate via appropriate primitives: shared events modeled as a problem spec (interface & allowable sequences) Simulation for Modeling Process environment modeled as state machines communication system Set 14: Simulations Layered model

  22. layer 1 layer 2 layer 3 Simulation for Modeling Process (Cont.) environment Send Send Send Send communication system Set 14: Simulations Propagation of events

  23. Modeling Process Specifications (1) • A system consists of • A collection of n processors (or nodes), p0 through pn-1 • A communication system C linking the nodes • Environment E • Notes • Environment E and Communication system C are given as problem specifications • Node is a hardware notion • Running on each node are one or more processes • Processes are organized into a single stack of layers • The same number of layers on each node Set 14: Simulations

  24. Modeling Process Specifications (2) • Each process is state machine (modeled as an automaton) • Has a set of states, including a subset of initial states • Has hour kinds of events • Inputs coming in from the layer above (or the environment, if this is the top layer) • Outputs going out to the layer above • Inputs coming in from the layer below (or the communication system, if this is the bottom layer) • Outputs going out to the layer below • Events of type 1 and 2 form the top interface of the process • Events of type 3 and 4 form the bottom interface of the process Set 14: Simulations

  25. layer i - 1 layer i layer i + 1 Top interface of layer i 1 2 Bottom interface of layer i 4 3 Set 14: Simulations Propagation of events

  26. Modeling Process Specifications (3) • Events • Concepts • An event is said to be enabled in a state of a process if there is a transition from that state labeled with that event • Inputs from the environment and from the communication system are called node inputs • A configuration of the system specifies a state for every process on every node • A configuration does not include the state of the communication system • An initial configuration contains all initial states

  27. Modeling Process Specifications (4) • An execution of the system is a sequence C0 e1 C1 e2 C2 … of alternating configurations Ciand events ei • If it is finite, ending with a configuration • Satisfies the following conditions • C0is an initial configuration • event ei is enabled in Ci-1(there is a transition from the state(s) of the relevant process(es) in Ci-1 labeled ei) • state components of processes change according to the transition functions for ei • can chop the execution into pieces so that • each piece starts with a node input • all events in each piece occur at the same node • the next node input does not occur until no events (other than node inputs) are enabled

  28. Definition of Admissible Execution Set 14: Simulations • We only require an algorithm to be correct if • each process is given enough opportunities to take steps (called fairness) • the communication system behaves "properly" and • the environment behaves "properly" • Executions satisfying these conditions are admissible.

  29. Proper Behavior of Communication System Set 14: Simulations The restriction of the execution to the events of the interface at the "bottom of the stack" is an allowable sequence for the problem specification corresponding to the underlying communication system Example: message passing, every message sent is eventually received

  30. Proper Behavior of Environment Set 14: Simulations The environment (user) interacts "properly" with the top layer of the stack (through the interface events) as long as the top layer is also behaving properly. Mutex example: the user only requests to leave the critical section if it is currently in the critical section.

  31. Simulations Set 14: Simulations System C1simulates system C2 if there is a set of processes, one per node, called Sims.t. • top interface of Sim is the interface of C2 • bottom interface of Sim is the interface of C1 • For every admissible execution  of Sim, the restriction of  to the interface of C2 is allowable for C2 (according to its problem spec).

  32. Simulations C2 inputs C2 outputs C2 inputs C2 outputs C2 Sim … Sim0 Simn-1 C1 inputs C1 outputs C1 inputs C1 outputs C1 If user of C2 behaves properly and if C1 behaves properly, then Sim ensures that user of C2 thinks it is really using C2 (and not C1 plus a simulation layer) Set 14: Simulations

More Related