[linux-audio-dev] lock-free data structures

Joshua Haberman joshua at reverberate.org
Fri Jun 18 07:15:32 UTC 2004


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




More information about the Linux-audio-dev mailing list