Subject: [linux-audio-dev] Re: [Jackit-devel] questions about diskthread/process() synchronization
From: Kai Vehmanen (kai.vehmanen_AT_wakkanet.fi)
Date: Wed Nov 13 2002 - 18:54:11 EET
On Wed, 13 Nov 2002, Paul Davis wrote:
>>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.
I've browsed through the sparc arch manuals and couldn't find anything
that would limit atomic access to 24 bits nor any directly related cache
line limitations. The Linux asm-sparc/atomic.h provides only 24bits as
it uses the lower 8bits to implement a low-overhead spinlock. Spinlock
is required to guarantee memory ordering (also with mixed usage of
various atomic_* ops). If you just read/write 32bit ints, this is
atomic even on SMP-sparcs.
>>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:
Ugh, true, my mistake.
> 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.
Ok, this is a real problem, but I don't think using asm-arch/atomic.h
(which can guarantee ordered access to the buffer indices) helps
to solve this issue, so you might just as well use regular ints
as the atomic indices.
And this really is a corner case as the buffer would have to be close to
empty (something has already gone wrong!) to read old data from the
buffer, even on a SMP sparc or s390.
-- http://www.eca.cx Audio software for Linux!
This archive was generated by hypermail 2b28 : Wed Nov 13 2002 - 19:17:35 EET