17 Oct
2008
17 Oct
'08
4:02 p.m.
Olivier Guilyardi wrote:
Paul Coccoli wrote:
excuse my chiming in here, i'm not really much of a c programmer... but
how can this
- rb->read_ptr += n1;
- rb->read_ptr &= rb->size_mask;
+ rb->read_ptr = (rb->read_ptr + n1) & rb->size_mask;
fix anything?
iiuc, both versions are equivalent. a context switch could happen just
as well after the parenthesis has been computed..!?
putting stuff on one line doesn't make it atomic. maybe you are now
getting another compiler optimization that helps to hide the bug?
no offense, just trying to learn something...
jörn
--
jörn nettingsmeier
home://germany/45128 essen/lortzingstr. 11/
http://spunk.dnsalias.org
phone://+49/201/491621
Kurt is up in Heaven now.
On Fri, Oct 17, 2008 at 8:46 AM, Paul Davis
<paul(a)linuxaudiosystems.com> wrote:
Well, it looks like you had a fast but great insight here. I've turned all
statements of this kind into one-liners, and the jack ringbuffer now
(apparently) passes the test. I'd rather add the memory barriers to the
JACK code, but this could be a
race to see who does what first. A memory barrier is typically single
instruction. The complication tends to be defining them in a
sufficiently portable way.
Why do you suspect you need memory barriers? My
concern with
ringbuffer.c is the non-atomic ops on the read and write pointers.
They're marked volatile, but what I think you really want is make all
ops on those fields atomic. Stuff like this:
rb->read_ptr += n1;
rb->read_ptr &= rb->size_mask;
Looks like a problem to me. What happens if there's a context switch
in between those 2 statements?
NB: I only took a cursory glance at the code.