8 Jul
2011
8 Jul
'11
10:49 p.m.
On Fri, Jul 8, 2011 at 3:29 PM, Dan Kegel <dank(a)kegel.com> wrote:
On Fri, Jul 8, 2011 at 7:23 PM, Dan Muresan
<danmbox(a)gmail.com> wrote:
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.
(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.