Re: [Discuss-gnuradio] Thread-Safe Blocking?

[Frank Brickle]

Robert McGwier wrote:
> ...A sound
> system callback wants to feed and be fed and never get blocked.  When it 
> has new data, it should issue a semaphore release on the dsp/data  
> processing system...

To generalize this just a very little bit: any sort of mechanism will 
do, that will let the DSP processing block until the arrival of new data 
from the audio subsystem.

We happen to prefer semaphores when using pthreads, but that's entirely 
because the alternative under pthreads would be a combination of mutexes 
and condition variables. The alternative would mean more lines of code 
to accomplish exactly the same effect as semaphores. For uniformity we 
also use semaphores to guard critical sections, since there's no real 
overhead incurred over mutexes.

Along the same lines, where there are native blocking message queues, or 
an attractive library implementation like Eric is providing, that might 
be an even better choice than semaphores.

The basic point is that barriers or mutexes are not rich enough on their 
own for the callback/client DSP processing model. Some additional 
scheduling mechanism is necessary. It's most sensible to take advantage 
of whatever the OS or application environment provides for that purpose. 
If you're slightly crafty the implementation details will be hidden 
behind an opaque API layer anyway.

Frank
AB2KT