ExecutionManager - lms-org/lms GitHub Wiki

The ExecutionManager initializes, cycles and deinitializes modules. It cannot be called from within modules but instead the ExecutionManager invokes the lms::Module life-cycle methods.

Modules get initialized in the order they are mentioned in the <modulesToEnable> tag in XML configs.

Usually the ExecutionManager orders the modules by their dependency on data channels. The rule of thumb write-before-read applies here: Modules that write into data channels get executed before modules that are only reading.

Example 1:

• Module 1: writes to channel A
• Module 2: reads from channel A
• Module 3: reads from channel A and B
• Module 4: writes to channel B

Module 2 is dependent on module 1. Module 3 is dependent on module 1 and 4. This leads to following dependency graph:

Now the following execution orders are possible:

• 1, 2, 4, 3
• 4, 1, 2, 3
• 1, 4, 2, 3

The framework does not guarantee any of the orders.

If more than one module is writing into a single data channel then the order of execution is not specified. If the order is important one can set it via priority inside the <channelMapping> tag. Higher priorities get executed earlier than lower priorities.

Example 2:

• Module 1 (default priority of 0): writes to channel A
• Module 2 (priority 5): writes to channel A
• Module 3: reads from channel A

Because module 1 and 2 write to the same channel their priority is concerned during computation of the execution order. Module 1 is dependent on module 2 because of the different priority and module 3 depends on module 1 and 2 (write-before-read). This leads to this priority graph:

Now only one execution order is possible: 2, 1, 3.

The ExecutionManager can create a thread pool during framework startup and is capable of scheduling the modules to the created threads. Multithreading can be enabled with the --threads <POOL_SIZE> command line argument. Specify a positive integer as the number of threads to create or auto to automatically choose the best thread pool size depending on systems CPU.

Example 1 can be executed multithreaded.

Module 1 and 4 can be executed in parallel. If module 1 gets executed faster than module 4 then module 2 can be executed immediately. Module 3 can be executed only after module 1 and 4 got executed.

Even in multithreading mode the main thread is capable of executing modules but usually the main thread is only waiting for the threads in the pool to finish execution. This behavior can be overwritten with <mainThread /> in <module>. The module will be always executed on the main thread.