Super-threaded computing with GSequencer
Multi-threaded computing become common, nowadays. Normally you process a tree with on single thread and maybe update another one asynchronously. But what if you compute the tree in parallel? There comes the term super-threaded in. Basically anything could be super-threaded using a FIFO. But as sharing memory and protecting it by mutices you might encounter a dead-lock.
After reading following article you might think it would be ease. But you’re definitely wrong without limiting parallelism you even have a need for the nested tree:
The following article gives you a deeper insight how it is solved:
GSequencer has a solution, the nested recycling tree. It defines by the recycling context how audio data is accessed. Every recycling has its own thread and the iterator thread brings order into the chaos.
Recycling life-cycle
I’ve just created those meaningful float-charts with Dia to show you how the basic life-cycle goes. The first belongs to iterating the tree and locking the FIFO. The second is about processing audio data.
Like every thread in GSequencer the iterator thread is synchronized every run. There currently three playback modes and all of them form the playback domain. The iterator thread exists only for the domain and FIFO is unique within parent recycling.
The recycling thread exists three times one for each playback mode. All those threads wake-up at the very same time. They get signaled by the iterator thread and then process the audio data.
Interested in participating
http://gsequencer.org
https://github.com/gsequencer/gsequencer/wiki/super-threaded-computing
