Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Clone this wiki locally
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.