Threading
Table of Contents
GRAS is based on a back-end that implements the actor model. The actor model is a message passing architecture that is inherently thread-safe. The back-end understands the concept of threads, mutexes, etc. So GRAS only has to understand the concept of actors and messages. Therefore, when used correctly, thread-safety is inherent to the design.
GRAS uses the C++ Theron library which implements the actor model: http://www.theron-library.com/
More on the actor model from Wikipedia: https://en.wikipedia.org/wiki/Actor_model
GNU Radio implements two threading models: the single thread per flow graph, and the thread per block. GRAS intends to use a thread pool model. In this model, arbitrary blocks can be assigned to a pool of threads. Multiple pools of threads can be used to subdivide the flow graph into separable processing units.
To implement a single thread model, simply put all blocks into a thread pool with one thread. To implement a thread per block model, each block gets its own thread pool of size 1 thread. The default behaviour is 1 thread pool with N threads, where N is the number of cores.
See thread_pool.hpp for reference: https://github.com/guruofquality/gras/blob/master/include/gras/thread_pool.hpp
Thread pools have a highly configurable number of options:
- Thread affinity, processor groups and NUMA nodes
- Thread priority scheduling with OS
- Configurable spinlocks or condition variables
Example: A user might put their frontend DSP blocks into a high prio thread pool with OS prio that uses spin locks, and then put their MAC layer type of blocks in a low prio condition variable based thread pool.