|
From: | Robert McGwier |
Subject: | Re: [Discuss-gnuradio] gri_ringbuffer.{h,cc} |
Date: | Sun, 12 Mar 2006 21:47:01 -0500 |
User-agent: | Thunderbird 1.5 (Windows/20051201) |
The final resolution: if you find pathologies in the ring buffers, the ONLY safe place to reset them is in the callback itself, otherwise the callback can /**AND WILL**/ step on the rb reset. You cannot afford to semaphore, etc. in the callback of course, so a safe way is to use flags that are only read and reset in the callback when the rb resets occur. There are subtle race conditions that might occur but they are minor irritants compared to the stupidity of what we were doing.
All of the strange conditions we had in DttSP were caused by this programming bug. They no longer exist in DttSP v.2 which will be out next week and they don't exist in PowerSDR now. We only looked for this subtlety for months. A few well constructed tests finally resolved the problem.
Bob Eric Blossom wrote:
On Sun, Mar 12, 2006 at 10:20:16PM +0100, Stephane Fillod wrote:- against gnuradio-core: ot_gri_ringbuffer.patch * src/lib/general/gri_ringbuffer.{cc,h}, src/lib/general/Makefile.am: new lockless ringbuffer (single reader/single writer) taken from JACK software (GPL).Bob and Frank, Didn't the JACK ringbuffer code cause you problems when pushing "part of a float" into it. I.e., there was room for 3 bytes, but not all four. If this is true, how did you fix it? Specialize for only floats? "Yet another ringbuffer implementation" that doesn't have the problem? I can't see an occasion when we'd need anything other than floats. Eric
-- 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!
[Prev in Thread] | Current Thread | [Next in Thread] |