Threads and concurrency - summary points from presentation

Introduction
• Concurrency: More than one activity at the same time
• Models usually contain concurrent activity
• Models are inherently parallel programs
• The (runtime) engine itself only processes one activity at a time (even on dual CPUs).

Events And Their Ordering
• Events generate activity in a model
• Activity generates further events
• Events are sorted by time in the FEC
• Its not safe to rely on the order that events in the FEC at the same time will be processed
• Past models forced order using delays
• Order can be assured by understanding threads

Threads
• Items flow between points of capacity. A moving item (flowing) is a thread
• Events trigger item movement hence events trigger threads
• A thread generally cannot be interrupted
• All activities within one thread will occur together and in their flow sequence
• A thread ends when an item reaches a point of capacity
• Threads can post “side effect” events
• The next thread to execute is well defined for some specific cases

Co-ordinating Threads
• One to One vs. One to Many
• Attribute Gate (One to One)
• Messages (One to One)
• Normal, Directed, Immediate
• Broadcasts (One to Many)
• Global, Scoped, Directed
• Splitters (One to Many)
• Immediate Messages

Messaging from a dispatcher
• Gives a One to One co-ordination of threads
• Original item waits until message item completes and “returns”
• Thread order is maintained if the message item leaves in its original thread
• Can dynamically direct message to a location determined at runtime

Broadcasting from a dispatcher
• Combines One To Many and Wait Until
• Broadcasts all sent before item leaves
• Only guarantees execution of the initial thread after each broadcast entry
• Sending the broadcast to all entries takes higher priority than processing other events at the same time
• Unsafe to rely on the order that the entries will receive the broadcast

Avoiding Concurrency Problems
• Minimise creating simultaneous item threads when possible
• Use a single item to process events in a system to avoid concurrency issues and conflicts which are more likely with multiple items
• Call common code using messages
• Minimise capacity objects in threads to avoid creating extra events

Avoiding Concurrency Problems (2)
• Try perform any Graphical iteration without capacity objects in the loop
• Do not rely on the order that broadcasts get sent, items leave servers etc. Splitters are OK
• Use Immediate Messages to call a thread from within a routine (within a thread)

Cases where thread order is defined
• Empty Queue / normal Dispatcher which is not blocked moves item out in next thread
• Message/Broadcast Dispatcher - same
• Splitter which is not blocked
• Zero delay multiserver ONLY if thread is initiated by an FEC event - not a broadcast or splitter

Pausing Issues
• A model can only be paused between events, never within a thread, broadcast send etc.
• Earlier versions of Planimate could be paused between any pair of events
• This meant that a model could be paused before all events at the current time were processed, leading to incomplete updates.
• Engine now “pauses” only after all events at the current time have been processed

Future Directions
• User Thread - Persistent Items
• Handling graphical looping better
• Flexible class changes within a thread
• Threads spanning multiple instances/machines

---

idkbase note 206