In the current implementation, a Process begins running in Thread Q at EVENT_INIT_PRECONNECT, and will remain in Thread Q until it is destroyed. Future implementations will implement Dynamic Load Balancing and other advanced execution modes, that may violate this assumption. Processes may be moved, not only into different threads, but even onto different machines, within an Execution. If you are authoring a Process that may be sensitive to this, you should familiarise yourself with this information.
Run Phase (everything between an event pair EVENT_RUN_PLAY and EVENT_RUN_STOP) is considered sacrosanct, context-wise. Your Process will execute entirely within the context of a single thread. Outside of this phase, you should, in general, make no assumptions whatsoever and assume a different context on every event received.
Context Sensitivity Issues
BRAHMS optimises use of multiple local cores by running multiple scheduled processes in more than one execution thread, where appropriate, and when not explicitly forbidden. In addition, BRAHMS may also switch processes to run in different threads if it detects a load imbalance, and provided Dynamic Load Balancing is enabled (not yet implemented!). When running Concerto (i.e. multi-processing), BRAHMS may execute processes on separate machines, and may also move them around between machines if Dynamic Load Balancing is enabled.
Processes that only operate on instance-private state data (which can include their own input and output ports, and any data objects on them) should not have any problem with any of the above (most processes will be of this nature). Generally, if your Process does maintain context-sensitive resources, you should maintain them only within Run Phase.
If it is not possible to comply with any of the above, you may proceed as outlined in one of the three sub-sections below. See also Life Cycles.
Some processes will not be "thread-safe". This means that two instances of the process may not be executed concurrently (note that this does not mean that two instances of the process may not exist concurrently - if this is not safe, you need the as-yet-unimplemented flag F_SINGLE_INSTANCE). In particular, processes that use non-thread-safe third-party libraries (e.g. Matlab or Python) will have this problem. Such processes should set the flag
Some other processes will be thread-safe, but "thread-sensitive". This means that once a process has been begun in thread A, it is not safe to switch it to run in thread B. An example is a process that interacts with its parent thread - some GUI systems have such a restriction (though, generally, it will be possible to maintain GUI resources only during Run Phase, where thread switching is forbidden). Such processes should set the flag
Some other processes will be thread-safe, not thread-sensitive, but "voice-sensitive". This means that once a process has been begun on machine A, it is not safe to switch it to run on machine B (perhaps it interacts with hardware or some such). Such processes should set the flag
|This is a documentation page for the BRAHMS Modular Execution (Simulation) Framework. For details of licensing and distribution, please click here. To advise of an error or omission, please click here.|