Re: [LAD] a *simple* ring buffer, comments pls?

From: Paul Davis <paul@email-addr-hidden>
Date: Tue Jul 12 2011 - 23:36:35 EEST

On Tue, Jul 12, 2011 at 4:20 PM, Olivier Guilyardi <list@email-addr-hidden> wrote:

> Quite interestingly, I have noticed that discussions about memory barriers are
> often somehow endless. What happened in the past is that I saw countless
> discussions about whether they are needed, whether they are not, and people
> would argue a lot and passionately.

I think the problem is that memory barriers are almost never required
when writing "normal" code, and so people (including myself) are not
exposed to their implementation or their use very much. and indeed,
there are precious few library implementations of memory barriers, nor
are they widely documented in a way that suggests that their use is
"normal".

by contrast, they get used all over the place in the kernel
(relatively speaking), so if you tend to have a lot of exposure to
kernel code, then calls to mb() or whatever they use these days will
be quite familiar.

there's the additional problem that this discussion normally ends up
confusing two separate topics that many people seem to think are the
same (they are not):

   1) do you need to actively ensure correct thread-level synchronization
          between the reader and writer of a single-reader/single-writer FIFO?
          Put differently, do you need to use synchronization mechanisms
          semantically equivalent to a mutex to ensure that any
arbitrary execution
          order of the 2 threads does not cause incorrect behaviour?

   2) do you need memory barriers to ensure correct synchronization
         for this kind of data structure in the face of possible hardware level
         instruction reordering?

My feeling is that the answer to (1) is "no" and the answer to (2) is "yes".
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Wed Jul 13 00:15:02 2011

This archive was generated by hypermail 2.1.8 : Wed Jul 13 2011 - 00:15:02 EEST