On 12 July 2011 21:36, Paul Davis <paul@email-addr-hidden> 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@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:03 EEST