Telematics 2 & Performance Evaluation · Tele2 / Perf Eval (WS 19/20): 05 –Complex Queuing System 9 Process event: Task finishes service qPretty much identical to M/M/1 version

1Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System

Telematics 2 &Performance Evaluation

Chapter 5Complex Queuing System

(Acknowledgement: These slides have been prepared by Prof. Dr. Holger Karl)


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 simulationq 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


Overview

q A complex example: single queue, multiple serversq Future event setq Data structures for future event setsq Objectifying simulation designq Race conditions


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 airportsq 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 queueq If server becomes idle, and queue not empty, first job in queue will be

assigned to that serverq Arrival process and service time as beforeq All servers are assumed to be identical and independent of each other

q This is called an M/M/k queue (k = # servers)


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 informationq Actual number of servers to useq State of every server must be described � arrayq 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


Implementing M/M/k – Program structure

q Some obvious changesq Initialize all server-relevant variables, not just one

q Recall: Main parts of the program wereq Identify next eventq Process eventq Generate new eventsq Update statistics whenever suitable


Identify next event

q Which happens first – new task or task completion?

q Up to k tasks could be in progressq 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


Process event: Task arrives

q When customer arrives, check all servers to see if idle server existsq If idle server exists, assign this task to idle server

q Tie breaking!q Otherwise, put into queue


Process event: Task finishes service

q Pretty much identical to M/M/1 versionq Main difference: Server that becomes idle has to be identified and

manipulatedq When determining which server will finish first, also remember the index of

this server for reference here


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?


Overview



Restructuring event management

q Look closely how the next event is determinedq A set of variables describe the times for all the next eventsq Always the nearest event is usedq The kind of event determines which code is used to process that event

■ This is highly application-specificq 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


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 occurq 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


Future event set

q Operations to be performed on this setq 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 eventq If desired: functions for statistical purposes

q In essence, this is a priority queueq Well-known data structure; more details soon


Organization of the main program

q Use a priority queue to hold the future event setq 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 FESq Set time to the time of this event, update statisticsq 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 themselvesq Just put new events in the future event set, specifying their time of

occurrenceq Handler functions might event delete events from the FES, does not

happen hereq 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


Implementation issues – Version 4

q Have a look at version 4 of our example programq 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 queueq Similar to SIMQueueq Method push has a parameter �priority�, according to which the queue is

orderedq Usually, priority and time of the event will be identical – priority is

introduced here to make SIMPriorityQueue more general


Implementation issues – Version 4

q Main program has a SIMPriorityQueue of eventsq Main loop as described aboveq 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_eventq Puts an entry into the SIMPriorityQueueq Called by the handler functions

q All in all, a much clearer structure


Overview



Implementing a priority queue

q PriorityQueue implements a simple sorted, single-linked listq Simple to implementq Remove of first element happens in O(1)q However, inserting an element takes O(length of queue) – expensiveq Appropriate if the future event set is small

q Reduce search time during insertingq Subdivide the single list in a number of lists, each one only containing

events for a certain time interval, in consecutive orderq So-called indexed linear listsq 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�



q Sometimes faster: Heapq Keep the entries only semi-sortedq Divide-and-conquer approach: Think of the data as arranged in a treeq Invariant: Every node is smaller than its childrenq NO requirement on the relative priority of siblings!q Efficiently representable in an array (children of i are in 2i and 2i+1)

15

19 28

50 23 39 40

Array representation: 15, 19, 28, 50, 23, 39, 40



q Operations on Heapsq Remove top node:

■ Choose the smaller of its children and move it to the top. ■ Continue recursively in that child�s subtree.

q Inserting an entry: ■ Add new entry to an arbitrarily chosen leaf.■ Check if the new node is larger than its parent. ■ If yes, terminate.■ If no, exchange places with parent and recursively check with the new

parent. q Both operations are O(log(number of elements in the heap)), fast

implementations possible



q Proper choice of data structure/algorithm for priority queue depends on different factors

q Average size of the future event set■ Linked lists good for small FES■ Heaps appropriate for large FES■ Indexed lists have about the same speed (and are the most

complicated to implement)q Distribution of the event hold time (simulated time between inserting an

event and its occurrence)q Why bother at all?

q Generating and consuming events is the most basic activity of a discrete event simulation

q Future event set algorithm is usually crucial for the required running time of a simulation program

23

Example from [Len96]

!"#$%#&'()"*%$*$+,+#"*"-"(,*.",*/&!0"&"(,',/%(.!"#$%&'(%

)%*+,-.%&-#/0#-%$%'/..1&2'+-2/&(-%'3&2'+$#1&24%,(2-5#/0#61)+*%(-%7.+2$8#!+6/,"$%&'(%932-"6.%"31

!"#"$% &'('% )(*+,(+*")% -"*"% ".'/0$"&% -0(1% )0/+2'(03$% '$&,3/4'*"&%(3%50$&%3+(%-10,1%3$"%)13+2&%6"%+)"&%(3%0/42"/"$((1"% 7+(+*"% 8#"$(% !"(% 35% '$% "#"$(% &*0#"$% &0),*"("% "#"$()0/+2'(3*9% % :1"% $+/6"*% 35% ;"<% ,3/4'*0)3$)% '$&% 430$("**"5"*"$,")%')%-"22%')%(1"%=>?%(0/"%-"*"%/"')+*"&9%%:1"%"55",(35% (1"% &055"*"$(% =>?% '*,10(",(+*")% -')% ".'/0$"&9% % @'*03+)4'*'/"("*%)"((0$A)%-"*"%+)"&%(3%&"("*/0$"%(1"%,1'*',("*0)(0,)35%(1"%)(+&0"&%"#"$(%)"(%0/42"/"$('(03$)9:"#2&-,/)1'-2/&2;# <;# =>=;?7@AB>=;#@BCDA=?=# =>=;?# CBEFG<?HA# ?I=# =>=;?C# J?I=# C?<?=DI<;K=C#HL#?I=#CMC?=EN#<A=#C?HA=@#B;#?I=#0F?FA=#%>=;?#(=?#J0%(N"-I=# @<?<# C?AFD?FA=# <;@# ?I=# <GKHAB?IEC# FC=@# LHA# C?HAB;K# ?I==G=E=;?C# HL# ?I=# 0%(# B;LGF=;D=# ?I=# CO==@# HL# ?I=# CBEFG<?HA# ?H# <KA=<?#=P?=;?"-I=#EHC?#DHEEH;#@<?<#C?AFD?FA=C#I<>=#<GA=<@M#Q==;#C?F@B=@#<;@?I=BA# K=;=A<G# O=ALHAE<;D=# DI<A<D?=ABC?BDC# I<>=# Q==;# @=?=AEB;=@".HC?# B;>=C?BK<?BH;C# <CCFE=# ?I<?# ?I=# R=MC# <A=# A<;@HE# JSB?IF;BLHAE# @BC?ABQF?BH;NT# ?I=# ;FEQ=A# HL# C=<ADI# HO=A<?BH;C# BC# EFDIIBKI=A#?I<;#?I=#;FEQ=A#HL#B;C=A?BH;C#HA#@=G=?BH;C#<;@#?I=#=G=E=;??H#Q=#C=<ADI=@#HA#@=G=?=@#BC#<GCH#A<;@HEGM#DIHC=;"##&=>=A?I=G=CCTB;#?I=#D<C=#HL#?I=#0%(T#?I=#R=MC#<A=#;H?#F;BLHAEGM#@BC?ABQF?=@T#QF?CIHS# <# ABCB;K# ?=;@=;DMU# B;# ?I=# ><C?# E<VHAB?M# HL# D<C=CT# ?I=# LBAC?=G=E=;?# BC# @=G=?=@# <;@# <# ;=S# H;=# BC# B;C=A?=@"# # (HE=?BE=CA<;@HEGM# DIHC=;# =G=E=;?C# <A=# @=G=?=@T# QF?# ;H# H?I=A# C=<ADIHO=A<?BH;C#<A=#FC=@",==>=C#W:X#=P<EB;=@#><AB<;?C#HL#GBC?C#<;@#I=<OCT#QF?#?I=#@BLL=A=;?RB;@C#HL#?A==#C?AFD?FA=C#<;@#?I=#CRBO#GBC?#WYX#A=ZFBA=@#LFA?I=A#C?F@M"-I=# =P<EB;=@# @<?<# C?AFD?FA=C# S=A=8# HA@=A=@# CB;KG=7GB;R=@# GBC?TQB;<AM#?A==T#+4$7?A==T#67?A==T#Y7[7?A==T#I=<O#<;@#CRBO#GBC?"Y"#-3%#2&4%(-2!+-2/&-I=#Q=I<>BHA#HL#<#@BCDA=?=7=>=;?#CBEFG<?HA#JLAHE#?I=#>B=SOHB;?#HL?I=#0F?FA=#%>=;?# (=?N#S<C# CBEFG<?=@# B;# ?I=# LHGGHSB;K#S<M8#!"#=>=;?C#S=A=# B;C=A?=@# B;?H# ?I=# 0%(T# ?I=;# ?I=# $%&'( =>=;?# J?I=# H;=SB?I#?I=#CE<GG=C?#?BE=#C?<EON#S<C#?<R=;#HF?#HA#<#A<;@HEGM#DIHC=;=>=;?#S<C#@=G=?=@"##-IBC#OAHD=@FA=#S<C#A=O=<?=@#E<;M#?BE=C#<;@?I=#?BE=#C?<EO#HL#?I=#!"# =>=;?#S<C#?I=#CFE#HL#?I=#?BE=#C?<EO#HL?I=# EHC?# A=D=;?GM# A=EH>=@# \$%&'(\# =>=;?# <;@# <# A<;@HE# @=G<MDHEOF?=@# <DDHA@B;K# ?H# @BLL=A=;?# @BC?ABQF?BH;C"# # -I=# O<A<E=?=ACS=A=8# ?I=#;FEQ=A#HL# ?I=#=>=;?C# B;# ?I=#0%(T# ?I=# C?<?=#HL# ?I=#0%(J?A<;CB=;?# HA# C?=<@MNT# ?I=# OAHOHA?BH;# HL# ?I=# A<;@HEGM# @=G=?=@=>=;?C# <;@# ?I=# @BC?ABQF?BH;# HL# ?I=# @=G<M# J=POH;=;?B<GT# F;BLHAET<;@#?SH#;HAE<G#@BC?ABQF?BH;C#SB?I#@BLL=A=;?#@=>B<?BH;CN"

&FEQ=A#HL#=>=;?C#B;#?I=#0%(

?BE=WECX#

]^^_^^`^^::^^:[^^:]^^

:^ Y: ab :^^ Y:] aba :^^^

$BC?#J N$BC?#JQN6B;"?"#J N(RBO#$BC?+4$7?A==3Y [7?A==66B;"?"#JQN

0BK"#:"#%P=DF?BH;#?BE=#HL#:^^^#CBEFG<?BH;#C?=OCT#Bacb#)$'#OAHD"-H#@=?=AEB;=#?I=#O=ALHAE<;D=#DI<A<D?=ABC?BDC#HL#?I=#C?F@B=@#=>=;?C=?# <GKHAB?IECT# ?I=# ;FEQ=A# HL# R=M# DHEO<ABCH;C# <;@# HL# OHB;?=AA=L=A=;D=C#<C#S=GG#<C#?I=#'*1#?BE=#S=A=#E=<CFA=@"##6M#DI<;KB;K?I=#O<A<E=?=AC#HL#?I=#CBEFG<?BH;#EH@=G#HA?IHKH;<GGMT#CBEFG<?BH;CS=A=# AF;# SB?I# <GG# OHCCBQG=# O<A<E=?=A# DHEQB;<?BH;C"# # -I=

CBEFG<?BH;# S<C# O=ALHAE=@# H;# ?I=# LHGGHSB;K# OAHD=CCHAC8# 2;?=Gacb)$'T#2;?=G#acb)dT#)%'#+$*3+"["#,%(1$-(6M#=P<EB;B;K# ?I=#;FEQ=A#HL#R=M#DHEO<ABCH;CT#B?#S<C# LHF;@# ?I<??I=#Q<G<;D=@#?A==C#<;@#I=<O#OAH@FD=#?I=#GHS=C?#><GF=C#<EH;K#<GG?I=#@<?<#C?AFD?FA=C"##0HA#?IBC#A=<CH;T# BL#S=#FC=#<#OAHD=CCHA#SI=A=?I=#'*1#?BE=#HL#?I=#=>=;?#C=?#HO=A<?BH;C#BC#@HEB;<?=@#QM#?I=#R=MDHEO<ABCH;C#J?I<?# BCT# LGH<?B;K#OHB;?#HO=A<?BH;C#<A=#;H?# CFOOHA?=@QM#I<A@S<A=NT#Q<G<;D=@#?A==C#<;@#I=<O#<A=#?I=#Q=C?#DIHBD="##6B;<AM?A==# OAH@FD=@# KHH@# O=ALHAE<;D=# DI<A<D?=ABC?BDC# B;# ?I=# D<C=# HL=POH;=;?B<G#@BC?ABQF?BH;T#?IHFKI#B;#?I=#D<C=#HL#H?I=A#@BC?ABQF?BH;CQB;<AM#?A==#CIHS=@#SHAC=#A=CFG?C"#J0BK"#:"###QeQ=C?T#SeSHAC?#D<C=N/;# ?I=# H?I=A# I<;@T# CRBO# GBC?# OAH@FD=@# EFDI# Q=??=A# ?BE=DI<A<D?=ABC?BDC# ?I<;# ?I=# Q<G<;D=@# ?A==C#SI=;# <@><;D=@# I<A@S<A=LGH<?B;K#OHB;?#OAHD=CCB;K#S<C#FC=@"##J0BK"#Y"N

&FEQ=A#HL#=>=;?C#B;#?I=#0%(

?BE=WECX#

^:^^Y^^[^^a^^

:^ Y: ab :^^ Y:] aba :^^^ Y:]a aba:

$BC?#JSN $BC?#JQN Y7[7?A==+4$7?A== 67?A== 6B;"?"#JSN3=<O 6B;"?"#JQN (RBO$BC?

0BK"#Y"#%P=DF?BH;#?BE=#HL#:^^^^#CBEFG<?BH;#C?=OCT#)%'#+$*3+#OAHD"fB?I# C?AH;K# LGH<?B;K# OHB;?# CFOOHA?T# B?# BC# SHA?I# FCB;K# CRBO# GBC?A<?I=A# ?I<;# Q<G<;D=@# ?A==CT# =CO=DB<GGM# Q=D<FC=# B?C# <GKHAB?IEC# <A==>=;#CBEOG=A#?I<;#?I<?#HL#?I=#Q<G<;D=@#?A==C"a"#'/&'$1(2/&f=#DH;DGF@=@#?I<?#QH?I#?I=#OAHD=CCHA#?MO=#<;@#?I=#@BC?ABQF?BH;#HL?I=# @=G<M# HL# ?I=# ;=S# =>=;?C# B;LGF=;D=# SIBDI# @<?<# C?AFD?FA=OAH@FD=C#?I=#Q=C?#?BE=#OAHO=A?B=C"##-IHFKI#Q<G<;D=@#?A==C#OAH>=@?H# Q=# ZFB?=# KHH@T# I=<O# <;@# =CO=DB<GGM# CRBO# GBC?#S<C# LHF;@# ?H# Q=CBK;BLBD<;?GM#Q=??=A#H;#EH@=A;#OAHD=CCHA#<ADIB?=D?FA=C",%0%,%&'%(W:X ,==>=CT# '"# ."# :`ca"# \'HEOG=PB?M# +;<GMC=C# HL# %>=;?# (=?+GKHAB?IEC\#)*"+,-./0("&+1-0&!23##Y_"#;H"#:T#_Y7_`WYX *FKIT# 4"# :``^"# \(RBO# $BC?C8# +# *AHQ<QBGBC?BD# +G?=A;<?B>=# ?H6<G<;D=@#-A==C\#4-..0!5+-$+(*"+647##[[T#;H"#bT##bbc7b_b

Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System

24

For large event sets: Calendar Queues

q Put queued events in n bucketsq Each bucket is responsible for a time span t (analogue to a normal

calendar, e.g. one day)q Calendar cyclically wraps, i.e., event to be scheduled at time T, is put

into bucket (T/t) mod n

q Caveat: One must choose n and t wisely!q Too large data structure � caching inefficientq Too small data structure � too many events per bucketq Too large time span � too many events next bucketsq Too small time span � too many events in “wrong” buckets

q � Must be readjusted on the flyq Apart from that O(1) insertion and dequeue time!


25

Results from [Bro88]


26

Resizing is important! (From [OA99])



Overview



Generalizing the program structure

q Let us come back to the overall program structure of version 4q This structure – having a FES with events that define their handler

functions – is very flexibleq New functionality could be added by defining new handlers and

inserting events for these handlersq The underlying machinery of handling events remains the same

q However, much problem-specific functionality is still included in the main program


Generalizing program structure

q Would it not be nice to have such a machinery in place and only q Write own handlers, q Generate own events, q And provide own data structure for these handlers to work upon?

q How to organize the program to representq General simulation functionalityq Problem-specific functionality

separately?


Objectifying program structure

q Possible solution: Use object orientationq Use classes/objects to represent entities of the simulation modelq Have objects communicate by exchanging messagesq General functionality is only used to

q Organize exchange of these messages, q Create problem-specific objects, q Provide utility functions for statistics, etc.


Objects in an M/M/k model

q Separate functionality included in the model:q Load is generated independently of remainder of the modelq Servers are independent entities q Some logic is necessary that manages the actual queue and assigns jobs

to empty serversq Hence, use objects of three different classes:

q SIMLoadGenq SIMDispatcherq SIMServer

q Such objects are separate modules of a simulation program


Communication between objects

q These modules communicate only by exchanging messages q Arrivals of messages are eventsq Delivery of events/invocation of handler functions is organized by a

general-purpose simulation frameworkq Independent of particular classes

q Have a look at such an implementation – it is version 5 of our simulation program!

q For simplicity, the collection of statistics is not shown here, but it is straightforward to implement


A closer look: simulation framework

q Main program in SIMApp.cppq Only used to create objects, generates an initial event to get simulation

going, and execute event loopq Uses the well-known SIMPriorityQueue class to manage event

queueq Important functions that are generally necessary

q const double& now(): representing the current simulated timeq scheduleEvent(SIMEvent* e, const double& t): enqueue event

e into the SIMPriorityQueue priority queue such that event e will happen at time t


A closer look: simulation framework

q Events are represented using a class hierarchy q Starting with a simple class SIMEvent, containing a pointer to the

recipient (destination object) of the eventq Event-based classes contain methods to enable identification of the

derived class ■ Maybe done even if only a pointer to a base class is available

(dynamic_cast) – used e.g. in SIMServer (slow!!!)■ Better: add IDs

q Other types of events can be subclassed from this class, adding additional information to the event as needed

q Here, classes SIMTaskArrives and SIMTaskDone are defined as special types of events


A closer look: implementing modules

q Any class that implements problem-specific functionality (providing modules) needs to be derived from abstract base class SIMModule

q Class SIMModule only defines a handler function to be called when the module receives an event:virtual void handleEvent(SIMEvent* e) = 0;

q The classes SIMLoadGen, SIMDispatcher, and SIMServer are derived from SIMModule


A closer look: module SIMLoadGen

q A load generator contains the two random number generators for interarrival time and required service time

q It also needs to be told the dispatcher module: to whom shall the generated load (represented by SIMTaskArrives events) be delivered?

q Done in the constructor of the load generatorq Event handler is simple: Any time an event arrives, do the following:

q Generate a SIMTaskArrives event to be delivered to the dispatcher immediately (containing service time as parameter)

q Generate a simple event to be delivered to the load generator itself after the randomly generated interarrival time has passed


A closer look: module SIMServer

q A server module knows about three thingsq Its identityq Whether it is idle or notq The dispatcher module it works for (in order to return task completion

events to the dispatcher)q A server module knows how to do two things

q What to do when a new task arrives: handleTaskArrives()q What to do when the currently assigned task finishes:

handleTaskDone()


A closer look: module SIMServer

q Tasks are assigned to a server by sending a corresponding event to it from the dispatcher

q Server sets itself to BUSYq Schedules a SIMTaskDone event for itself

q At SIMTaskDone, server sets itself to IDLE and passes the event on to the dispatcher (to be delivered immediately)

q handleEvent() decides which kind of event arrived and calls the appropriate method


A closer look: module SIMDispatcher

q While load generator and server are fairly simple, dispatcher contains actual logic of the simulation

q Load generator sends SIMTaskArrives events to the dispatcherq Dispatcher scans set of servers by checking their idle statusq If idle server is found, SIMTaskArrives event is immediately sent to the

corresponding serverq If all servers are busy, an entry in a SIMTimedQueue object is made

q At arrival of SIMTaskDone event, dispatcher attempts to assign a queued job (if any) to a now idle server

q Similar to the server, dispatcher�s handleEvent() calls appropriate methods depending on the type of the arriving event


That’s it! Object-oriented simulation!

q Take a look at the code – it really is much simpler than the description sounds

q Overall structure is simple and straightforwardq Most important points:

q Strict separation of simulation engine from problem-specific modules and events

q New event types and module types can easily be used by subclassing the corresponding classes, without the actual simulation framework even being aware of this


Programming pattern used here?

q The modules themselves are also rather simple and follow a certain pattern:

q Wait for an event to arrive, q Decide what type of event it is, call the corresponding method that knows

how to handle that eventq Event handler modifies some of the module�s state (sets it to IDLE,

makes entries in a queue, …)q Generate some new eventsq And again wait for a new event to arrive

q You should recognize this pattern: the modules are extended finite state machines!

q Recall: Communication protocols are typically designed as eFSMs!q Typical programming style for discrete event simulation:

communicating extended finite state machines


Overview



But… does it work?

q Trying to run the code shown as version 5, you may – depending on the seed – notice some error messages from the server!q You may provoke the situation by changing scheduleEvent(e,

now()); to scheduleEvent(e, now() + 0.1);q At some points in time, a task is assigned when the server is not idleq Impossible!?! Dispatcher first checks a server’s idle status before it

sends a SIMTaskArrives event to a server!q How can it then be busy when a task arrives?


Assigning work to a busy server?

q Looking more closely at an execution, the problem only seems to happen when (at a certain time)

q The queue is not emptyq The load generator generates a job and sends it to the dispatcherq A server, at the same time, finishes a job

q Let us take a careful look at the event queueq Important point: in this implementation of the priority queue, events that

happen at the same time are executed in the order in which they were entered into the queue!

q Recall the discussion about tie breaking for simultaneous events?


Event queue snapshots at time t

q Server receives SIMTaskDone, sets itself idle, sends SIMTaskDone to dispatcher

q Load generator generates load, sends SIMTaskArrives to dispatcher, sends LoadGenevent to itself (t� > t)

toServer:taskDone, t

toLoadGen:GenLoad, t

toDispatcher:taskDone, t

toLoadGen:GenLoad, t

toDispatcher:taskDone, t

toLoadGen:GenLoad, t�

toDispatcher:taskArrives, t


Event queue snapshots at time t

q Dispatcher receives SIMTaskDone, retrieves job from job queue, generates a SIMTaskArrives for server (which is idle at this moment!)

q Dispatcher receives SIMTaskArrives , scans server, finds the still empty server (the SIMTaskArrivesevent has not yet arrived at the server, even though everything happens �simultaneously�), and sends this job to the server as well!


toDispatcher:taskArrives, t

toServer:taskArrives, t




(event inserted

here)

(event inserted

here)


Race condition

q Server will receive the two SIMTaskArrives eventsq The first one is okq The second one would assign a job to an already busy server, which is

impossible and generates an error messageq This is a typical example of a race condition

q The two jobs (one from the queue, one from the load generator) are �simultaneously� assigned to the same server, because the state information in the server has not been updated in time (�immediately, but not soon enough�)

q Dangerous and often difficult to find problem in simulation programs!q Sometimes even in commercial tools, where – even worse – no source

code is available


Race conditions – ways out?

q Assign priorities to different types of eventsq In this example, SIMTaskArrives message to servers are more

important than SIMTaskArrives messages to the dispatcher, as state information in the server needs to be updated to reflect the decision already taken by the dispatcher

q Priority queue is not only sorted by time, but also by priority (which one is the primary key?)

q Often simple to do in small simulations, difficult to handle in large cases



q Break information hidingq In a sense, being idle/busy is a property of a server and should be

represented there and no where else ■ Avoid redundant representation of state is a basic rule of object

orientationq However, this caused the dispatcher’s need to communicate with the

server to obtain its idle statusq Representing this state in the dispatcher (which does know the state)

removes this needq Again: simple in small programs, but can become a nightmare in larger

systems when the redundant information is not updated correctly in all replicas



q Be extremely careful about mixing different ways of information flowq In this example, the dispatcher assigned jobs by means of scheduling

events, yet retrieved information from the server module via C++ method calls

q These types of information flows are not synchronized, hence the query �Are you idle?� could overtake the assignment of the job

q Querying the server with special events is possible, server answers with corresponding events – should avoid race conditions of this type

q Disadvantage: can multiply the number of event/message types, runtime overhead for scheduling events is considerably higher than method invocations


Repairing this example?

q All three methods are feasible here – no cure-all to all problemsq Solutions not shown – left as an exercise J

q I will be glad to include any good solutions into next year’s courseq But this is quite a mess, really: Could we not have a tool that takes

care of some of these issues?q Yes – we will look at such a tool in the chapter after the following

q Nevertheless, simulation program logic must be sound no matter which tool is used


Conclusion

q Concept of future event set and event handlersq Think of it in terms of individual events, along with appropriate

handlersq Structure program as to manage events in a general fashion

q Future event set is a priority queue, with time of occurrence of events as priority

q Algorithms for implementing priority queuesq Modules communicating via events, based on object-oriented

simulation design, and simple to use and represent communicating extended finite state machines

q Race conditions can introduce subtle bugs into simulations, often because of bad design, often no really clean solution

q And what about your program�s results?

Telematics 2 & Performance Evaluation · Tele2 / Perf Eval (WS 19/20): 05 –Complex Queuing System 9 Process event: Task finishes service qPretty much identical to M/M/1 version

Documents