On Fri, Jul 8, 2011 at 3:29 PM, Dan Kegel <d...@kegel.com> wrote: > On Fri, Jul 8, 2011 at 7:23 PM, Dan Muresan <danm...@gmail.com> wrote: >> (http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html): >>... >> The only thing that volatile accomplishes is to slow down >> properly-synchronized programs. volatile is for signal handlers and >> interrupt handlers, not for threading. >>... >> This reordering cannot be prevented without proper synchronization. So >> my advice to anyone considering this would be to drop volatile and do >> proper synchronization at the application level (i.e. semaphores, >> since it has to work in real time). > > +1 > > volatile is not the droid you're looking for.
could be true enough, but i will be happy to fake ignorance and say i don't know for sure. but ... the whole point single reader/single writer lock-free FIFOs is that *synchronization doesn't matter*. to state it again: the whole essence of the design is that the reader and writer can execute with any timing behaviour whatsoever and the "worst" that can happen is that they each think there is less data/space available than there actually is. the design is NOT attempting to implement a synchronized interaction at all, because it is not necessary. this is why we don't care about the types of stuff that Dan Muresan mentioned, except to the extent that it could actually lead to the computation of data/space available being wrong in a deeper way. we do NOT care about synchronization for these data types unless it could actually cause the value of one of the indexes to be accessed at a time that is "intermediate" in the sense of being "between two C expressions". it appears that at this time, this is not possible on any architecture that you might be sensibly using lock free FIFOs with. IF we had a processor pipeline that was really big enough and really did enough runtime optimization across the entire pipeline, then i can imagine how this could turn into a problem. but AFAIK (and again this subject has been hashed to death many times here and elsewhere), current processors do not have this architecture and there's no sign of them being imminent or even that desirable. _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev