It’s about time that I tackled the concurrency problem.
I need to send audio data from the processor to the editor (for some advanced metering). I also have some existing code locking for some communications from the editor to the GUI. It’d be good to replace that with something that’s considered less likely to cause problems.
From all that I've read - the solution is a FIFO.
I need to decide how general I make the solution. For example it would be easy to copy the ThreadedAudioWriter example and adapt it for sending streams of audio to the editor.
But a better solution might allow sending objects and messages of any kind.
I’m only trying to tackle the problem where there are two threads. One sensitive one: the audio thread, and the other not so.
For the editor sending data to the processor it seems simple to allocate an object. Then put a pointer to the object into the FIFO. The consumer of the FIFO handles the object and pops the pointer into another FIFO back to the editor’s thread. The editor’s thread then deletes the object.
Is that a reasonable solution?
But that won’t work the other way around – when I’d need to be allocating objects in the processor – which I’m presuming I can fix with some kind of object pool … or custom memory allocation.
Vinnie might have a solution … but I don’t yet understand boost::bind and ‘functors’ . Off to do some more reading on that and the supercollider code.
Also is anyone using the boost::lockfree library - which looks like it overlaps a little with the AbstractFIFO.