Skip to content

Threading

Josh Blum edited this page May 9, 2013 · 12 revisions
http://www.theron-library.com/images/theron.logo.png

Inherent thread safety

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

http://wcl.cs.rpi.edu/salsa/tutorial/salsa-1_1_0/actor_model.jpg

Thread pool 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

Configurable performance

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.

Something went wrong with that request. Please try again.