[linux-audio-dev] Re: [Jackit-devel] questions about diskthread/process() synchronization

Kai Vehmanen kai.vehmanen at wakkanet.fi
Wed Nov 13 09:54:01 UTC 2002

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.

 Audio software for Linux!

More information about the Linux-audio-dev mailing list