Section 53: Event List Management Discrete-Event Simulation: A First Course c 2006 Pearson Ed, Inc 0-3-4297-5 Discrete-Event Simulation: A First Course Section 53: Event List Management / 3
Section 53: Event List Management Large NES may have thousands of events in the event list Such a NES will spend most of CPU time on managing event list Efficient event management will reduce overall CPU time Structures also applicable to SJF queue discipline Discrete-Event Simulation: A First Course Section 53: Event List Management 2/ 3
Introduction Event list: data structure of events, plus any extra associated info Elements in the list: event notices List size classifications: Fixed maximum No need for dynamic memory allocation Variable or unknown maximum Application: A specific model We can exploit model characteristics General-purpose (eg, simulation language) Need robust DS Discrete-Event Simulation: A First Course Section 53: Event List Management 3/ 3
Event list operations Critical operations: Insert / enqueue Schedule an event Delete / dequeue Usually: process the next event Rarely: cancel an already-scheduled event Other operations (not considered here): Change operation Search to change an attribute (eg, scheduled time) Examine operation Search to read an attribute Count operation How many event notices in list? Discrete-Event Simulation: A First Course Section 53: Event List Management 4/ 3
Event list criteria Speed Balance between sophisticated DS and overhead Consider average-case and worst-case performance Robustness Performs well for many scheduling scenarios General purpose: performs well for many simulation models Use diverse, representative benchmark models Adaptability Adapt to changes in event distributions Adapt to changes in event list size Parameter-free Discrete-Event Simulation: A First Course Section 53: Event List Management 5/ 3
Conceptual Model: a computer timesharing system Think Type Receive Computer user endlessly cycles: Thinking: requires Uniform(0, 0) seconds 2 Typing: Equilikely(5, 5) keystrokes for the command Uniform(05, 035) seconds per keystroke 3 Receive output of command: Equilikely(50, 300) characters of output /20 seconds to display each character (constant) Discrete-Event Simulation: A First Course Section 53: Event List Management 6/ 3
Conceptual Model: simplifications Always exactly n users at n terminals All users think at same rate All users type at same rate No interaction between users No load on system: Command execution time is always instantaneous Receive rate remains fixed Are the distributions appropriate? Discrete-Event Simulation: A First Course Section 53: Event List Management 7/ 3
Rough analysis: simulated time Average think time is ( ) 0+0 2 = 5 seconds Average type time is ( ) ( 5+5 05+035 ) 2 2 = 25 seconds ) ( 20) 4583 seconds Average receive time is ( 50+300 2 Average cycle time is 5 + 25 + 4583 = 89583 seconds Steady-state probability of thinking, typing, receiving: 5 89583 056 25 89583 028 4583 89583 06 Discrete-Event Simulation: A First Course Section 53: Event List Management 8/ 3
Rough analysis: scheduled events Average think events per cycle: Average keystroke events per cycle: ( ) 5+5 2 = 0 Average display character events per cycle: ( ) 50+300 2 = 75 Average number of events per cycle: + 0 + 75 = 86 Expected fractions of event types: 86 0005 0 86 0054 75 86 094 Most scheduled events are display character Discrete-Event Simulation: A First Course Section 53: Event List Management 9/ 3
Specification Model Events for each user (field type): Complete thinking time 2 Complete a keystroke 3 Complete character display Events (2) and (3) require extra information (field info) Number of keystrokes remaining in command Number of characters remaining to display Simplistic event-list structure: Array of size n with fields time, type, info O() for insert operation O(n) for delete operation Discrete-Event Simulation: A First Course Section 53: Event List Management 0/ 3
Simple event list Users initially thinking time 9803 3507 305 255 8243 type info 0 2 3 4 At time 305, user 2 finishes thinking: Generate Equilikely(5, 5) keystrokes: 7 Generate Uniform(05, 035) time for first keystroke: 030 Schedule keystroke completion at time 305 + 030 = 606 time 9803 3507 606 255 8243 type 2 info 7 0 2 3 4 Subsequent keystrokes for user 2 decrement info field Discrete-Event Simulation: A First Course Section 53: Event List Management / 3
Algorithm 53, main t = 00; for (i = 0; i < n; i++) { event[i]time = GetThinkTime(); event[i]type = ; } while (t < τ) { j = MinIndex(event); /* scan the event list */ t = event[j]time; /* update clock */ if (event[j]type == ) DoneThinking(j); else if (event[j]type == 2) DoneKeystroke(j); else if (event[j]type == 3) DoneDisplay(j); } Discrete-Event Simulation: A First Course Section 53: Event List Management 2/ 3
Algorithm 53, details DoneThinking Method DoneThinking(int j) { /*Schedule first keystroke*/ event[j]time += GetKeystrokeTime(); event[j]type = 2; event[j]info = GetNumKeystrokes(); } DoneKeystroke Method DoneKeystroke(int j) { event[j]info ; /*Decrement remaining keystrokes*/ if (event[j]info > 0) event[j]time += GetKeystrokeTime(); else { /* Schedule first display */ event[j]time += 0 / 200; event[j]type = 3; event[j]info = GetNumCharacters(); } } Discrete-Event Simulation: A First Course Section 53: Event List Management 3/ 3
Program ttr Implements Algorithm 53 Counts total number of events scheduled Counts total number of event notices searched Terminates at time τ = 00 seconds Average number of cycles per user: 00 89583 6 Average number of events per user: 6 86 = 20763 Discrete-Event Simulation: A First Course Section 53: Event List Management 4/ 3
Performance of simple event list Run ttr with seeds 23456789, 98765432, 555555555 Compute averages over three runs # users Theoretical Average # Average # n Avg# events events searches / event 5 0 38 9 902 5 0 20 763 20 678 0 50 93 84 9 669 50 00 207 628 20 949 00 Number of events is consistently lower than theoretical average Due to initial bias (initially thinking) Discrete-Event Simulation: A First Course Section 53: Event List Management 5/ 3
Improved event list management Use an ordered event list (ie, times are sorted) Use linked list instead of array (faster insertion) Insertion is O(n) in worst case, O() in best case Deletion is O() Structure for searching head to tail (ie, most recent in front) head 606 255 3507 8243 9803 2 7 next next next next next tail Most recent in back: reverse pointers, search tail to head Discrete-Event Simulation: A First Course Section 53: Event List Management 6/ 3
Ordered list performance Using most recent in back: # users Average # Average # n events searches / event 5 9 902 383 0 20 678 8 50 9 669 4055 00 20 949 89 But from earlier analysis: Most events are display character Display character has very short duration Most events scheduled for near future We should use most recent in front Discrete-Event Simulation: A First Course Section 53: Event List Management 7/ 3
Ordered list performance, most recent in front # users Average # Average # n events searches / event 5 9 902 72 0 20 678 273 50 9 669 045 00 20 949 98 Discrete-Event Simulation: A First Course Section 53: Event List Management 8/ 3
Advanced event list management Further discussion is for general case: Number of events in list varies 2 Maximum size of event list is unknown 3 Structure of simulation model is unknown We will discuss four structures: Multiple linked lists 2 Binary search trees 3 Heaps 4 Hybrid schemes Other structures exist Discrete-Event Simulation: A First Course Section 53: Event List Management 9/ 3
Multiple Linked Lists Use k ordered lists Insert into shortest list: worst case O(n/k) Delete is O(k): check front of each list Example for k = 2, n = 0 for ttr: 305 255 3507 8243 9803 head next next next next next tail 22 2220 3020 453 959 head next next next next next tail Discrete-Event Simulation: A First Course Section 53: Event List Management 20/ 3
Issues for Multiple Linked Lists Should k be fixed, or allowed to vary? If fixed, what is a good k? If variable, decide When to increase or decrease k (as a function of n) How to increase k: split lists or start new? How to decrease k: merge lists? Discrete-Event Simulation: A First Course Section 53: Event List Management 2/ 3
Binary trees Recall: Each node has at most 2 child nodes, and at most one parent node The node with no parent: root A node with no children: leaf Node level: if root, +parent s level otherwise Tree height: maximum level Discrete-Event Simulation: A First Course Section 53: Event List Management 22/ 3
More on binary trees Full tree: All leaves at same level All non-leaves have 2 children Complete tree: Full down to level h Level h is filled left to right Discrete-Event Simulation: A First Course Section 53: Event List Management 23/ 3
Binary search trees 453 2220 959 255 3507 8243 9803 305 22 3020 Node property: Left child value Node value Right child value Discrete-Event Simulation: A First Course Section 53: Event List Management 24/ 3
Binary search trees for event lists Leftmost node is most imminent Worst-case insert: O(h) Worst-case delete: O(h) Unbalanced trees: easier to implement Height of tree h can be as large as n Balanced trees: need to rotate nodes Height can be limited to h = O(log n) AVL, red-black, Splay trees are examples Discrete-Event Simulation: A First Course Section 53: Event List Management 25/ 3
Heaps 305 2220 255 3020 453 9803 22 8243 3507 959 Node property: Node value Left child value, right child value Discrete-Event Simulation: A First Course Section 53: Event List Management 26/ 3
Heaps as event lists Always a complete binary tree Root node is most imminent Insert, delete: maintain heap property by swapping nodes with parent Easier to implement than balanced binary search trees Worst-case insert: O(log n) Worst-case delete: O(log n) Searching for arbitrary event: O(n) Discrete-Event Simulation: A First Course Section 53: Event List Management 27/ 3
Hybrid schemes If n is small, a simple structure may work best If n is large, a tree structure should work well One hybrid scheme: change data structures Eg: When n increases above 5, change to heap When n decreases below 6, change to ordered list Discrete-Event Simulation: A First Course Section 53: Event List Management 28/ 3
Henriksen s algorithm Uses binary search tree and ordered list simultaneously Ordered list: Doubly linked Ordered by event time Contains dummy events with time and Binary tree: Nodes for a subset of event times Node format: Pointer to next lower time tree node Pointer to left child tree node Pointer to right child tree node Event time Pointer to the event notice Discrete-Event Simulation: A First Course Section 53: Event List Management 29/ 3
Example of Henriksen s DS 3507 0 0 0 0 305 + head prev prev prev prev 305 four 3507 four + other other event event next next notices next notices next dummy real real real real dummy tail Discrete-Event Simulation: A First Course Section 53: Event List Management 30/ 3
Operations using Henriksen s algorithm Deletion: from front of list, tree is not fixed, O() Insertion (time t): Find smallest time larger than t in tree 2 Search backwards in list at most l positions (usually l = 4) 3 Position found: insert 4 Position not found: pull operation to rebalance tree: Go to next lower time node in tree Change that tree node to point to current list entry Continue search at step (2) If next lower time node not present, add a new level to tree Tends to have short average insertion time Implemented in simulation languages: GPSS, SLX, SLAM Discrete-Event Simulation: A First Course Section 53: Event List Management 3/ 3