Runtimes & Race Conditions

When you're building a graph of events to run logic, it's natural to assume things will run in the order of:

A -> B -> C

But SEL allows for disconnected graphs. So what happens if your model is actually:

A -> B

and separately, on its own little island:

C

Will C run before B?

In a traditional, line-by-line (procedural) language this is straightforward: functions on line 1 will run before functions on line 2.

But, SEL doesn't have lines?

Simulated time

As shared The Summit Way, SEL runs in a simulated environment, which means there are 3 perspectives on time and SEL:

Processing time: how long it takes for the model's code to run.
Response time: how long it takes for you to receive results from the model.
Simulated time: how much virtual time elapses in the model.

While it is possible to build models that do not use any simulation time (they start and stop at "time zero"), the events nevertheless occur at a certain "moment in time". If you open the log view in the Summit IDE, you will see date and times for all events that occur. Going back to the A or C riddle above, each event is assigned a default start time that determines their order of execution.

Order of operations

These events all occur at the first moment (time=0), in parallel. If A and C are any of these, the answer to the riddle is that they run in parallel:

Counter
Wait
Every
Timespring
Time
String
Formulas (e.g. =2+3)

A Gate event will run immediately following the events above.

Next,Source and any events that are not listed elsewhere.

Then, in order:

Funnel
Wheel
Pool
Text
Request

Exceptions

An event will never run before an event that points to it, regardless of what type it is. For example, if:

Pool -> Time

The Time event will run after the Pool event because it is downstream.

Also, if an event has a recurring pattern ("run hourly"), that pattern will break the natural order and force the event to run at that moment in simulated time.