Telematics 2 & Performance Evaluation Chapter 7 Complex - PDF document

Telematics 2 & Performance Evaluation Chapter 7 Complex Queuing System (Acknowledgement: These slides have been prepared by Prof. Dr. Holger Karl) Telematics 2 / Performance Evaluation (WS 17/18): 07 – Complex Queuing System 1 Goal of this chapter q Understand implementation issues and solutions for a more complicated example q Develop the concept of a future event set and its use in a simulation q Along with appropriate, fast data structures for such sets q Using object orientation in simulation programs q Develop a typical programming style for simulations, based on object- oriented design of simulation programs q Some reasons and cures for some subtle programming bugs Telematics 2 / Performance Evaluation (WS 17/18): 07 – Complex Queuing System 2

Overview q A complex example: single queue, multiple servers q Future event set q Data structures for future event sets q Objectifying simulation design q Race conditions Telematics 2 / Performance Evaluation (WS 17/18): 07 – Complex Queuing System 3 Single queue, multiple servers q Consider a system where multiple servers are used to serve a single queue q Often found in, e.g., check-in lanes at airports q Model: q If at least one server is empty, arriving job will go to that server (ties are broken arbitrarily, e.g., in increasing numerical order) q If all servers are busy, arriving job will join end of queue q If server becomes idle, and queue not empty, first job in queue will be assigned to that server q Arrival process and service time as before q All servers are assumed to be identical and independent of each other q This is called an M/M/k queue (k = # servers) Telematics 2 / Performance Evaluation (WS 17/18): 07 – Complex Queuing System 4

Implementing M/M/k q Reusing classes SIMQueue , SIMTask evidently possible (without any changes) q How to structure the main program? q Changes against M/M/1 version discussed q State information q Actual number of servers to use q State of every server must be described � array q Statistic-gathering variables need to be extended: keep utilization of every server separate ■ How to interpret this? Think of tie-breaking rules between idle servers! q Fairly straightforward, really Telematics 2 / Performance Evaluation (WS 17/18): 07 – Complex Queuing System 5 Implementing M/M/k – Program structure q Some obvious changes q Initialize all server-relevant variables, not just one q Recall: Main parts of the program were q Identify next event q Process event q Generate new events q Update statistics whenever suitable Telematics 2 / Performance Evaluation (WS 17/18): 07 – Complex Queuing System 6

Identify next event q Which happens first – new task or task completion? q Up to k tasks could be in progress q Identify the first task to complete q Compare this task � s departure time to arrival time of new task q This gives the next clock value Telematics 2 / Performance Evaluation (WS 17/18): 07 – Complex Queuing System 7 Process event: Task arrives q When customer arrives, check all servers to see if idle server exists q If idle server exists, assign this task to idle server q Tie breaking! q Otherwise, put into queue Telematics 2 / Performance Evaluation (WS 17/18): 07 – Complex Queuing System 8

Process event: Task finishes service q Pretty much identical to M/M/1 version q Main difference: Server that becomes idle has to be identified and manipulated q When determining which server will finish first, also remember the index of this server for reference here Telematics 2 / Performance Evaluation (WS 17/18): 07 – Complex Queuing System 9 Discussion q Updating statistics is straightforwardly extended from simpler version q Processing the events is also reasonably increasing in complexity q Identifying the next event, however, becomes inordinately more complex q Not clear how to generalize that even further without getting lost in application-specific details q This is version 3 of the example program – look at source code on the course web page q Can we not do any better? Telematics 2 / Performance Evaluation (WS 17/18): 07 – Complex Queuing System 10

Overview q A complex example: single queue, multiple servers q Future event set q Data structures for future event sets q Objectifying simulation design q Race conditions Telematics 2 / Performance Evaluation (WS 17/18): 07 – Complex Queuing System 11 Restructuring event management q Look closely how the next event is determined q A set of variables describe the times for all the next events q Always the nearest event is used q The kind of event determines which code is used to process that event ■ This is highly application-specific q Sometimes, additional information is also provided ■ E.g., the number of the server on which the task has been running ■ Also, highly application-specific information Telematics 2 / Performance Evaluation (WS 17/18): 07 – Complex Queuing System 12

Future event set q What is actually needed? q A data structure to describe a set of events that will occur in the future (future event set, FES) q Each event is associated with q The time at which it will occur q The particular procedure that shall be called when this event occurs (to handle this event) ■ The so-called � handler function � q Additional information as parameters for this procedure Telematics 2 / Performance Evaluation (WS 17/18): 07 – Complex Queuing System 13 Future event set q Operations to be performed on this set q Enter a new event ■ Along with additional information ■ In particular, the time of occurrence of the event q Remove (and return) the first event ■ Irrespective of the order in which events have been added, order of removal is only dictated by the explicitly given time for each event q If desired: functions for statistical purposes q In essence, this is a priority queue q Well-known data structure; more details soon Telematics 2 / Performance Evaluation (WS 17/18): 07 – Complex Queuing System 14

Organization of the main program q Use a priority queue to hold the future event set q Main program is a loop that continues as long as stopping rule is not true (and there are events to be processed) q Extract next event from queue holding the FES q Set time to the time of this event, update statistics q Call the handler function for this event (included with the event) ■ Passing parameters as included in the event information to this procedure q New events are generated by the handler functions themselves q Just put new events in the future event set, specifying their time of occurrence q Handler functions might event delete events from the FES, does not happen here q Initialization: Just put one or more events in the future event set q No need to � poison � some kinds of events as they do not even exist yet Telematics 2 / Performance Evaluation (WS 17/18): 07 – Complex Queuing System 15 Implementation issues – Version 4 q Have a look at version 4 of our example program q SIMEvent.hpp contains declaration of q Prototype for handler functions: typedef void (*handler_fct) (int); Handler functions only take a single integer as parameter q Class SIMEvent , containing time of occurrence, a handler function pointer, and some arbitrary data that is to be passed to the handler function q SIMPriorityQueue.hpp defines a priority queue q Similar to SIMQueue q Method push has a parameter � priority � , according to which the queue is ordered q Usually, priority and time of the event will be identical – priority is introduced here to make SIMPriorityQueue more general Telematics 2 / Performance Evaluation (WS 17/18): 07 – Complex Queuing System 16

Implementation issues – Version 4 q Main program has a SIMPriorityQueue of event s q Main loop as described above q Event handler functions for arrival of task and departure of task q Essentially identical to the code blocks that were originally in the main loop q Explicit function schedule_event q Puts an entry into the SIMPriorityQueue q Called by the handler functions q All in all, a much clearer structure Telematics 2 / Performance Evaluation (WS 17/18): 07 – Complex Queuing System 17 Overview q A complex example: single queue, multiple servers q Future event set q Data structures for future event sets q Objectifying simulation design q Race conditions Telematics 2 / Performance Evaluation (WS 17/18): 07 – Complex Queuing System 18

Implementing a priority queue q PriorityQueue implements a simple sorted, single-linked list q Simple to implement q Remove of first element happens in O(1) q However, inserting an element takes O(length of queue) – expensive q Appropriate if the future event set is small q Reduce search time during inserting q Subdivide the single list in a number of lists, each one only containing events for a certain time interval, in consecutive order q So-called indexed linear lists q A number of variations how to choose these intervals ■ All span the same time (equidistant) ■ Dynamically adjusted so that the number of elements in each list is constant ■ Only sort events that are � near in time � Telematics 2 / Performance Evaluation (WS 17/18): 07 – Complex Queuing System 19 Implementing a priority queue q Sometimes faster: Heap q Keep the entries only semi-sorted q Divide-and-conquer approach: Think of the data as arranged in a tree q Invariant: Every node is smaller than its children q NO requirement on the relative priority of siblings! q Efficiently representable in an array (children of i are in 2i and 2i+1) 15 28 19 23 39 40 50 Array representation: 15, 19, 28, 50, 23, 39, 40 Telematics 2 / Performance Evaluation (WS 17/18): 07 – Complex Queuing System 20