[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Robert McGwier
Subject: Re: [Discuss-gnuradio] gri_ringbuffer.{h,cc}
Date: Sun, 12 Mar 2006 23:38:01 -0500
User-agent: Thunderbird 1.5 (Windows/20051201)

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.


AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats,
Laziness is the number one inspiration for ingenuity.  Guilty as charged!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]