September 25, 2015

Super-threaded computing with GSequencer

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:

super-threaded computing

The following article gives you a deeper insight how it is solved:

the only way

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.

iterator thread

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.

recycling thread

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



Click Here!