On 12 July 2011 21:36, Paul Davis <p...@linuxaudiosystems.com> wrote: > 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?
The transactional metaphor for this kind of thing seems useful -- the idea that "we've written everything, now we commit for our readers" feels like a helpful way to picture the points where barriers might be necessary. Since transactional integrity is not provided for us, the commit needs to be either * protected with a memory barrier, if it doesn't matter that the data is available before it has been announced but does matter if the data is announced before being available * an atomic swap, if the new data must not be available before it has been announced and also there is only a single point of reference to the new data * mutex protected, if the references to any changes may be significant or we are not confident of either of the previous cases ...? Chris _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
