12 Jul
2011
12 Jul
'11
11:16 p.m.
On 12 July 2011 21:36, Paul Davis <paul(a)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