This action might not be possible to undo. Are you sure you want to continue?
about distributed discrete event simulation. Construct a framework for distributed discrete event simulation of messagepassing systems. Use your system to perform a simulation of a "car wash" system. Introduction: A discrete event is something that occurs at an instant of time. For example, pushing an elevator button, starting of a motor, stopping of a motor, and turning on a light, are all discrete events because there is an instant of time at which each occurs. Activities such as moving a train from point A to point B are not discrete events because they have time durations. However, we can model an event like this as two separate discrete events: the event of the train leaving point A, and the event of the train arriving at point B. If we associate a time value with each discrete event, then we can model the duration activities as the difference between the times associated with the events marking the beginning and the end of each activity. For example, we can specify that the arrival at point B occurs 3 hours and 37 minutes after leaving point A. Therefore, we can see that if the train leaves point A at 7:53pm, then it will arrive at point B at 11:30pm. The purpose of a discrete event simulation is to study a complex system by computing the times that would be associated with real events in a real-life situation. In the train example above, suppose that we know that when the train arrives at point B, a load is transferred to a second train that arrives at point C after 45 minutes. That is, the second train's departure from point B is triggered by the first train's arrival, and the arrival at point C occurs with a delay of 45 minutes after the departure from point B. In this simple example, we can use discrete event simulation to determine that the second train will arrive at point C at 12:15am. One way to carry out a simulation is to use the real-time clock (the clock on the wall) to time the delays, and to read the value on the clock as each event completes in order to see what would happen. However, this would take unnecessarily long. For example, it would be silly to wait 3 hours and 37 minutes to determine the arrival time of the first train when a simple calculation suffices. So, the idea of a discrete event simulation is to compute, as quickly as possible, the physical times that "would" occur in real time in a
before it processes an event with time t. Some events may cause new events to be put into the local event queue. Like the sequential version. and the program processes the events in increasing time order. in which we will guarantee that events cannot arrive out of order. (For example. It is not a problem if some of the simulators are "ahead" of others in terms of the times that they are assigning to events. a simulator must be certain that it will not be receiving any more events to process with times earlier than t. some of the events may need to be sent elsewhere for processing.physical system. but here are some ideas. each simulator maintains its own event queue and processes events in time order. However. In other words. . so it would put that new event in its queue. Sometimes. this knowledge is available automatically: if a simulator has already received events with times greater than t from each of its incoming neighbors. However. if a simulator does not receive an event with time greater than t from one of its neighbors. but without actually waiting for the delays between events to occur in real time. this is desirable. it "rolls back" the simulation to an earlier point and restarts from there. then it is safe to advance its local simulation to time t. To accomplish this in a sequential program. one assumes that such a problem will not occur. and has built-in knowledge about how each kind of event causes other events to be added to the event queue. one uses a queue of events that are ready to be performed. In an "optimistic" approach to distributed discrete event simulation. at time t+5. Another way of saying this is that we cannot allow time to go "backwards" at any of the simulators. processing events in its event queue. There are many possible approaches to solving this problem and every solution some advantages and disadvantages. it can be helpful to distribute the work of processing events across many simulators. In fact. However. We will let you decide on your own solution to this problem. and. with each simulator responsible for processing certain kinds of events. We assume that each simulator knows the set of "incoming neighbors" (simulators from which it might receive events). the trick is that you must guarantee that no simulator receives an event whose time is earlier than any event already processed by that simulator. it may have to wait indefinitely before processing the next event. it may know that if one event occurs at time t. then a related event should occur 5 time units later. The program is started with one or more events initially in the queue. Each simulator may proceed independently. This event queue is kept sorted in increasing time order. However. because otherwise the events would be processed out of order. we will use a "conservative" approach. if a problem does arise. If a simulator knows that the current simulation time of each of its incoming neighbors is greater than time t. When simulations grow large and have a lot of concurrency (have many events that could be processed simultaneously). then it is safe for the simulator to process events at time t or earlier.
Then read over the rest of the assignment before starting. an attendant who decides where each car should go. The car wash is viewed as a message-passing system consisting of several distinct components: a source where cars enter the system.Each simulator can periodically send its current simulation time to its outgoing neighbors. However. These "null" messages let the neighbors determine if it is safe to advance the simulation. Attendant CW2 CW1 Source Sink The components have the following functionality: . However. Overview of the Simulated System: In this project. it can "poll" each of its incoming neighbors to determine its latest simulation time. you will construct a distributed discrete event simulation of a car wash. many of these messages may be sent needlessly because a simulator is not waiting for them. If a simulator is waiting. If each responds with a time greater than t. two or more physical car wash stations. then it is safe to advance the simulation to time t. A schematic diagram of message communication among these components is given below. even if it has no real events to send them. causing a lot of message traffic even if the neighbors have not advanced in time. it could become necessary to poll repeatedly until each neighbor reaches time t. Directions: Be sure that you have read the introduction carefully. and an exit where cars leave the system.
For example. You may assume that it takes 0 time units to send a car from the source to the attendant. the event [18. If multiple car wash stations are idle. Sequential simulator (optional): (As a stepping stone to your distributed discrete event simulation system. In addition. Car wash stations: Wash cars. then each arriving car is queued at the attendant. you may want to start by implementing a sequential discrete event simulator. your simulator . Initially. named as CarWasher2. it is sent to the exit. and the closing time (when the source will stop sending new cars into the system).Source: Generates cars at random times and sends them to the attendant. If one or more car wash stations is idle (not busy washing a car). ready to accept another car. attendant. You may assume that it takes 0 time units to send a car from the Attendant to a car washer. Your simulator should maintain a sorted event list and process events in time order. The washing time of each station is fixed (an input parameter to your program). If all car wash stations are busy washing cars. To process each event. if any. Car10] denotes that the attendant sends Car10 to Station3 at time 18. Each event has a sender. and insert any triggered events (with appropriate times) to the event list with the appropriate times. Station3. The parameters of your program should be: the number of car wash stations.) Implement a sequential discrete event simulator. content. a receiver. you should remove it from the event list. at a minimum. PRINT out the name of the event which includes the time at which it occurs. and its associated time. Remember that it is legal for one event to trigger multiple events. but different car wash stations may have different washing times within the same simulated system. the arrival of a car at a car wash station may cause two new events to be queued: sending a car to the exit and sending an "idle" message to the attendant. then the car at the head of the queue. You will not turn in this part of the assignment. However. Note that two parameters are used for the car source to generate cars. you should understand how you would design the sequential version before tackling the distributed one. is sent to that an idle car wash station. After each car is washed. one at a time. For example. allowing you to control both the minimum and maximum time intervals between the arrival of two cars. and the car wash station notifies the attendant that it is idle. Attendant: Directs cars to the car wash stations according to the following rules. the processing time of each station (separately). all car wash stations are idle. it's up to the attendant where to send the next car. so you may be tempted to go straight to the distributed version. the range of random numbers chosen for the arrival times of the cars (smallest random number and largest random number).
one simple approach is to let the CarSource module sending a "Terminate" (or "NULL") message after it finishes generating cars. Otherwise. Station: You will instantiate this module multiple times. receiver. construct a simple visualization of your simulation system. sender. In your distributed simulator. Distributed Simulation: Now modify your simulator so that it can be used for distributed discrete event simulation. and the terminate time. Whenever a module removes an event from its event queue for processing. content].). content of message. Note: To avoid deadlock at the end of the program. or even in the form of [time. Source: The parameters of this module include smallest random number. content]. Attendant: The only parameter of this module is the number of car wash stations. all modules can terminate gracefully. The meanings of these parameters are the same as in the sequential version above. content]. depending upon how you design your system. Your main task is to implement 3 types of modules. message passing is achieved by publishing a tuple whose type matches that of the message. Output/Visualization: Using your favorite visualization tool or writing a simple window of panels/icons. Also note that the messages the attendant receives may not be in time order due to the nature of distributed simulation. For each instance. Be sure to test your sequential simulator thoroughly. The inputs are messages received from the attendant and the outputs are messages sent to an exit module. you will provide a parameter that indicates the amount of time this car wash station needs to wash one car. the Attendant and all CarWashers will wait indefinitely. updated over . The attendant does not have to know the processing time of each car wash (unless you want it to). or in the form of [time. The message can be in the form of [time. receiver. largest random number. especially if you plan to use the code as a building block for your distributed simulation. the Attendant processes the "Terminate" message by forwarding the "Terminate" message to all the car washers. After delivering all queued cars. etc. it should print out all the information about that event (time. you could have the attendant publish its queue length. Note that it is safe for the attendant to process an event with time component t only when it can be certain that it has already received all messages with times up to time t. In this way.should maintain a car queue which keeps track of the cars queued at the attendant. For example.
you could have each station publish a flag saying whether or not it is busy.) Turn in a demonstration and code/design review. (The results from Phase 1 should help you!) What to turn in: Clean up and print out your code. different components will be operating at different logical times simultaneously. explain your design and code. Then you could connect this status information for visualization. (Don't turn it in. you should still print out the events processed by each component. but save it for your code/design review. Also. and answer questions during the demo/presentation day.) Keep in mind that as you watch the system. and length of time to wash a car at each station. You should be prepared to demonstrate your working application.) Use either TCP or UDP protocol for communication among the components of the system. etc. If you want to get fancy. termination time. you could allow the user to control the input parameters for the modules (such as the random values for car arrivals.time. (Even if you do a fancy visualization. .
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue listening from where you left off, or restart the preview.