>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
>[EMAIL PROTECTED]
>https://lists.sourceforge.net/lists/listinfo/jackit-devel
>
