Re: [boost] Flow-based programming library for Boost?

Subject: Re: [boost] Flow-based programming library for Boost?
From: Julian Gonggrijp (j.gonggrijp_at_[hidden])
Date: 2012-12-15 21:51:06

Marcus Tomlinson wrote:

>> Note that in a sense the DSPatch wire is a special case of the 
>> producer-consumer queue where the buffer has only one slot, so it's 
>> always either full or empty, forcing the producer and consumer 
>> components to work strictly in tandem.
> 
> Can I just quickly clarify that DSPatch does make use of producer-consumer pattern -Signals are buffered. The consumer has a slot per thread used to process the circuit (4 threads : 4 slots in each buffer). While one signal is being processed by the component, other incoming signals are being queued. Remember, one of the core features that DSPatch provides is the ability to run DSPatch circuits using no threads at all. This approach to the producer-consumer problem is designed as such to be scalable in this respect.

It appears that this doesn't change anything about the fact that 
components are forced to work strictly in tandem. Regardless, some 
questions for further clarification:

- Who owns the buffers? The circuit?
- Who are the producers/consumers? The threads?

If both of my guesses are correct, am I right to conclude that the 
threads are rotating over the components, and that the one-slot-per-
thread approach to the buffers is the way to ensure that they can read 
and write concurrently without a need for locking?

-Julian