13 Nov
2002
13 Nov
'02
11:59 a.m.
Actually I've spent some time studying this issue
and
my conclusion is that the level of atomicity provided by
linux asm-arch/atomic.h is not needed to implement
single-reader-single-writer lock-free buffers.
this is true unless the pointer/index isn't atomic. since on SMP sparc
systems, the arrangement of the cache lines means that you can't
guarantee better than 24 bit atomic values, you do have to be careful
about the potential size and memory position of the pointer/index
variables.
More specifically, asm/atomic.h provides guaranteed
ordering of reads and writes. This is not really needed
in handling the l-f buffer indices. In the worst case
reported write-space is larger, or read-space smaller,
than the actual situation.
actually, the worst case for both metrics is that they are *smaller*
than they should be. this happens on two occasions:
1) the write thread has written more data, but has
not yet updated the write pointer.
2) the write pointer has advanced the write pointer,
and it has gone "beyond" the end of the buffer.
the pointer will be "folded" back to the
start of the buffer, but this hasn't happened yet.
the situation is symmetric for the read side of things.
The only problematic scenarios are that a) read
returns
an invalid value, and b) write stores an invalid value.
These could possibly happen if reads/writes were not
atomic.
its not so much "atomicity" as "ordered" that is needed here.
because
read/write will only use that part of the buffer indicated as
available by the r/w pointers, all we have to know is that the writes
to the buffer complete before the write pointer is updated. it would
be good to use a so-called "memory barrier" somewhere there to make
sure this is true.
--p
But so far I haven't found any platforms (with
publically available specs) which don't guarantee
this
level of atomicity (even in the case of complex processor
cache arrangements).
The two architectures for which asm-xxx/atomic.h contains
special code even for plain reads and writes are SMP-sparc
and s390. I haven't studied s390, but at least in the case
of sparcs (ref: sparc v8 arch manual), reads and writes are
atomic even in a SMP configuration, although ordering is not
guaranteed. More specifically, if TSO (Total Store Ordering)
memory mode is selected, loads do not necessarily appear in
order. If using PSO (Partial SO), stores as seen by the
issuing processor can be executed out-of-order. But these
restrictions aren't really a problem for l-f buffers.
If I've interpreted the situation incorrectly, or someone
has better information, I'd be very interested to know!
Even better, example code that demonstrates atomicity
problems... I have currenly access to both IA32 and
Sparc-v8 multi-processor machines.
--
http://www.eca.cx
Audio software for Linux!
-------------------------------------------------------
This sf.net email is sponsored by: Are you worried about
your web server security? Click here for a FREE Thawte
Apache SSL Guide and answer your Apache SSL security
needs: http://www.gothawte.com/rd523.html
_______________________________________________
Jackit-devel mailing list
Jackit-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-devel