Runtime threading model

Learn how runtime threads, pools, and dispatch rules affect NetLogic execution, task selection, and performance.

Overview

FactoryTalk Optix Applications
 use multiple execution models. Runtime work does not run on one global thread. The runtime uses a shared priority-based thread pool, a timer pool, and dedicated subsystem threads.
This model affects how NetLogic code runs, how callbacks are serialized, and how system load changes application behavior.

Shared thread pools and dedicated threads

The shared priority-based thread pool runs general runtime work. The runtime schedules work by priority and available worker threads. The timer pool handles timer-based callbacks. Some subsystems use dedicated threads instead of the shared pools.
Dedicated subsystem threads isolate work that must stay responsive or ordered. Communication drivers can use their own threading model, based on driver design and protocol needs.

Dispatch and serialization

The runtime uses affinity-based dispatch for many operations. Work that targets the same runtime object or execution context can run in the same affinity and in serialized order. Serialization reduces concurrent access to the same state, but it does not mean that all runtime work runs on one thread.
Independent objects or subsystems can run in parallel on different threads. Shared resources still require thread-safe design when code can run from different contexts.

NetLogic execution model

NetLogic code can run from different runtime contexts.
Start()
 and
Stop()
 follow the NetLogic lifecycle rules described in NetLogic lifecycle. Exported methods, event callbacks, timers, and asynchronous tasks can run on different threads, based on the caller and runtime scheduler.
Do not assume that later calls reuse the same thread. Design NetLogic code so that shared state is explicit, limited, and protected when concurrent access is possible.

Long-running work

LongRunningTask
 is the preferred option for long or blocking operations that must access the information model. It separates long-running work from lifecycle execution and helps keep runtime behavior responsive.
Use
async/await
 or .NET thread-pool APIs only for work that does not access project nodes. For API details, see Constructor: LongRunningTask(action, executingNode).

Hardware considerations

Runtime throughput depends on both CPU core count and CPU clock speed. More cores increase potential parallelism. Higher clock speed improves single-thread performance and serialized workloads.
Hyper-Threading, or simultaneous multithreading (SMT), can improve CPU use, but logical cores do not match the performance of more physical cores. Performance gains depend on workload type, blocking behavior, and contention.

Design principles

Use these principles when you design NetLogic code for runtime execution:
  • Keep
    Start()
     and
    Stop()
     short.
  • Move blocking or long-running work to
    LongRunningTask
     or another suitable task type.
  • Avoid assumptions about thread identity or callback order across subsystems.
  • Protect shared mutable state.
  • Reduce contention on shared resources.
  • Test under realistic CPU load, I/O load, and communication load.
Provide Feedback
Have questions or feedback about this documentation? Please submit your feedback here.
Normal