13 Nov
2002
13 Nov
'02
10:53 a.m.
Btw; I'll cc'd this to lad, as this is a topic that
has been discussed there _many_ times. More
specifically the SMP-sparc case has been mentioned
quite a few times but without specific details.
For lad-only readers, see the jackit-devel archives
for the whole thread.
On Wed, 13 Nov 2002, Tim Goetze wrote:
it should be noted that this relies on accesses to
the
r/w buffer indices to be atomic. that's no problem on
common workstation hardware, though.
[...]
/usr/src/linux/include/asm-<target>/atomic.h
gives more
info.
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.
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.
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. 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!