Re: [Discuss-gnuradio] gri_ringbuffer.{h,cc}

[Robert McGwier]

Frank Brickle wrote:
> Robert McGwier wrote:
>
> > There are subtle race conditions that might occur but they are minor 
> > irritants compared to the stupidity of what we were doing.
>
> In particular you'd want to make sure any values that can be read in 
> the callback are set atomically in the client code. That includes 
> flags that trigger resets in the callback.
>
> Bob's recounting of our joint mental blunder is a little 
> oversimplified. My operating principle was that, once the callback is 
> started, the ring buffers are *never* reset. This is correct in 
> principle but unworkable in practice. Unfortunately the resets were 
> kind of wedged into the code and not properly thought out, by me mostly.

Actually,  this exact same error was in and DID occur in the dead bug 
version naked buffer exchange code .  On PTT I memset the buffer to zero 
to stop transmit noise from entering receiver code and vice versa.  And 
of course, the callback can and did overwrite this operation.  There is 
enough ooopsie to go around on this one for sure.
> The proper way to do this, of course, would be via something like an 
> "around" method applied to the callback. Since that's not a 
> possibility, the correct thing is still to wrap a ring buffer 
> management layer around the jack buffer processing, but all inside the 
> callback routine itself.
>
> Frank


--
AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats,
NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman
Laziness is the number one inspiration for ingenuity.  Guilty as charged!