Slide 1
Monitor
P2
C2
IO
Dispatcher
Elevator status information to be created around the concept of a Monitor, with built in producer/consumer synchronisation. It should feature suitable interface functions to allow processes to do the things they need to function.
For example an elevator could call Update_Status() which would wait to make sure both Dispatcher and IO have read the last update, then write new data to the data pool, then signal to both Dispatcher and IO that new data is available. Such actions would involve appropriate reading, signaling and waiting on the appropriate semaphores.
Of course you could add other functions to the monitor as dictated by the needs of each process and your algorithm/code.
P1
C1
P4
C4
P3
C3
Elevator 1
Elevator 2
Update_Status()
Update_Status()
IO process has three threads, one to handle updates from each of the two elevators and redraw the screen and one to handle input of commands from keyboard using polling and calling a function such as getch() or getche() to read a keyboard press. IO threads will attempt to get the status of each elevator. They may get blocked if there is no new data. They then update the screen using a function such as move_cursor() etc in the RT library. These two threads will need to synchronize with each other so that do not move the cursor at the same time, i.e. they will need to use a mutex M1.
Elevators only have one thread each. They block waiting for a command from the dispatcher (sent via the signal/mailbox) and then execute them with a suitable time delay between each.
Typed Pipeline between IO and Dispatcher allows incoming commands that have been validated by the IO process to be given to the Dispatcher, where upon the Dispatcher decides which elevator to delegate the command to e.g. floor or up/down request.
Dispatcher process has three threads and uses status of elevators so that it can decide which elevator is in the best position to deal with an incoming up/down request. Two of the threads respond to changes in elevator status and copy that status to local variables within the process so that when a new command arrives, it can be dealt with immediately
Get_Elevator_Status()
Get_Elevator_Status()
Get_Elevator_Status()
Get_Elevator_Status()
Elevator 1 Status
in
out
Elevator 2 Status
in
out
Signal/Mailbox to hold commands sent from Dispatcher to Elevator
Signal/Mailbox to hold commands sent from Dispatcher to Elevator
Signal/Mailbox to indicate dispatcher has terminated at end of simulation
Monitor
Additional rendezvous objects, conditions, events etc can be used at your discretion to synchronise processes/threads, as can the use of timers and other messages, plus of course the use of additional threads or active objects.
M1
Dispatcher is the parent process that creates other processes and environment
Typed Pipe1
Part A
You will need to create “Named” monitors as they are being shared between processes
Monitor
P2
C2
IO
P1
C1
P4
C4
P3
C3
Elevator 1
Elevator 2
Update_Status()
Update_Status()
Passengers are active objects created at random times and request random transport, e.g. up/down at a floor, wait for an elevator to arrive, get on, request a floor, travel, get off and are destroyed. Multiple passengers share a single pipeline Pipe2 that they enter their data/status too (up to you to figure out what is needed) and thus need a mutex M2 to protect the pipeline from being written to by more than one passenger at a time. Pipeline and Mutex M2 could even be in the form of a monitor.
A passenger starts by entering an up or down request, then polls on the corresponding up/down condition for both elevators for the floor the passenger is currently stood at e.g. EV 1 UP[0] or EV2 UP[0] if passenger waiting to go UP from floor 0. When an elevator arrives at that floor and opens its doors, the elevator will signal that corresponding condition to allow waiting passengers to get on (or off). Passenger getting on then enter a destination floor. Elevator closes the door and resets the condition. Numbers of passengers on elevator could be displayed
Get_Elevator_Status()
Get_Elevator_Status()
Get_Elevator_Status()
Get_Elevator_Status()
Elevator 1 Status
in
out
Elevator 2 Status
in
out
Signal/Mailbox to indicate dispatcher has terminated at end of simulation
Monitor
M1
IO is parent process that creates other processes and environment
Passengers
Typed Pipe2
M2
UP[0] – UP[9]
Conditions EV2
DW[0] – DW[9]
UP[0] – UP[9]
Conditions EV1
DW[0] – DW[9]
Part B
Active
Objects
Dispatcher
Passengers
Passengers
Passengers
Passengers
Passengers
Passengers
Passengers
Typed Pipe1
Add a synchronisation feature that limits the max number of passengers in each elevator at any one time to 4
/docProps/thumbnail.jpeg