Olivier Guilyardi wrote: > Paul Coccoli wrote: >> On Fri, Oct 17, 2008 at 8:46 AM, Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx> wrote: >>> 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. > > 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. 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. _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
