Re: Am I or Alexandrescu wrong about singletons?
On Mar 26, 12:05 pm, Andy Venikov <swojchelo...@gmail.com> wrote:
James Kanze wrote:
If that's the case, then the fence instruction is seriously
broken. The whole purpose of a fence instruction is to
guarantee that another CPU (with another thread) can see the
changes. (Of course, the other thread also needs a fence.)
Hmm, the way I understand fences is that they introduce
ordering and not necessarily guarantee visibility. For
example:
1. Store to location 1
2. StoreStore fence
3. Store to location 2
will guarantee only that if store to location 2 is visible to
some thread, then the store to location 1 is guaranteed to be
visible to the same thread as well.
A StoreStore fence guarantees that all stores issued before the
fence are visible in main memory, and that none issued after the
fence are visible (at the time the StoreStore fence is
executed).
Of course, for another thread to be guaraneed to see the results
of any store, it has to use a load fence, to ensure that the
values it sees are those after the load fence, and not some
value that it happened to pick up earlier.
But it doesn't necessarily guarantee that the stores will be
ever visible to some other thread. Yes, on certain CPUs fences
are implemented as "flushes", but they don't need to be.
If you redefine fence to mean something different than it
normally means, then who knows. The normal definition requires
all writes to have propagated to main memory (supposing it is a
store fence) before the instruction procedes. This is why they
can be so slow. (And all of the processors I know guaranteed
coherence within a single core; you never need a fence if you're
single threaded.)
--
James Kanze
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]