View
0
Download
0
Category
Preview:
Citation preview
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)
2Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
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
3Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
Overview
q A complex example: single queue, multiple serversq Future event setq Data structures for future event setsq Objectifying simulation designq Race conditions
4Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
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)
5Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
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
6Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
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
7Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
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
8Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
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
9Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
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
10Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
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?
11Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
Overview
q A complex example: single queue, multiple serversq Future event setq Data structures for future event setsq Objectifying simulation designq Race conditions
12Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
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
13Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
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
14Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
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
15Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
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
16Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
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
17Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
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
18Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
Overview
q A complex example: single queue, multiple serversq Future event setq Data structures for future event setsq Objectifying simulation designq Race conditions
19Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
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�
20Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
Implementing a priority queue
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
21Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
Implementing a priority queue
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
22Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
Implementing a priority queue
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!
Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
25
Results from [Bro88]
Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
26
Resizing is important! (From [OA99])
Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
27Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
Overview
q A complex example: single queue, multiple serversq Future event setq Data structures for future event setsq Objectifying simulation designq Race conditions
28Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
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
29Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
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?
30Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
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.
31Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
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
32Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
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
33Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
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
34Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
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
35Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
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
36Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
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
37Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
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()
38Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
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
39Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
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
40Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
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
41Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
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
42Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
Overview
q A complex example: single queue, multiple serversq Future event setq Data structures for future event setsq Objectifying simulation designq Race conditions
43Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
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?
44Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
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?
45Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
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
46Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
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!
toLoadGen:GenLoad, t�
toDispatcher:taskArrives, t
toServer:taskArrives, t
toLoadGen:GenLoad, t�
toServer:taskArrives, t
toServer:taskArrives, t
(event inserted
here)
(event inserted
here)
47Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
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
48Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
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
49Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
Race conditions – ways out?
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
50Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
Race conditions – ways out?
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
51Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
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
52Tele2 / Perf Eval (WS 19/20): 05 – Complex Queuing System
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?
Recommended