Subject: Re: [linux-audio-dev] lock-free data structures
From: Joshua Haberman (joshua_AT_reverberate.org)
Date: Fri Jun 18 2004 - 10:15:32 EEST
On Jun 17, 2004, at 11:25 PM, Tim Hockin wrote:
> On Thu, Jun 17, 2004 at 08:22:29PM -0700, Joshua Haberman wrote:
>> One final thing: I'm not sure if this is a problem in practice, but
>> most (if not all) processors do not guarantee that memory reads and
>> writes are performed in order, as observed by other processors and by
>> I/O devices. This could theoretically lead to a problem where the
>> stores that write data to the ring buffer are not performed until
>> *after* the store that updates your write pointer. Your reader thread
>> could get old data rather than the data your just wrote. To guarantee
>> that the loads and stores are observed in the required order, you have
>> to use memory barriers (again, in theory). See:
>
> Yes, this was discussed here a while back. For all practical platforms
> that the developers cared about, 32 bit aligned access are atomic.
That is orthogonal to the issue that memory barriers address. Even if
loads and stores are atomic, that does not guarantee that they happen
in program order, as observed by other processors and by I/O devices
(such as a sound card).
The example in the wikipedia article illustrates the error scenario. I
will adapt it here for the case of audio buffers:
thread 1:
memcpy(ringBufferVector, sourceBuffer, bufferLen);
written = 1
thread 2:
loop while written != 1
read RingBufferVector
If thread 1 and thread 2 are running on different processors in SMP,
out of order execution could cause the store "written = 1" to be
visible to thread 2 before all of the memcpy stores are.
Actually, glancing at the Linux source code it *appears* as though
memory barriers are not required on x86. However, they are necessary
on ppc; see (http://lxr.linux.no/source/include/asm-ppc/system.h#L17).
I don't know about other architectures.
Josh
This archive was generated by hypermail 2b28 : Fri Jun 18 2004 - 10:09:47 EEST