Subj : Re: an interesting threading-question
To   : comp.programming.threads
From : Oliver S.
Date : Thu Sep 15 2005 06:31 pm

> An optimizer will not perform optimizations that alter the visible
> effects of a program (assuming a single-threaded program model).
> You can think of the CPU as a hardware-level optimizer and make
> the same assertion: a CPU will not perform optimizations that
> alter the visible effects of a program (assuming the same single
> -threaded model).

Of course not and I didn't assume that in my post.

> At the hardware level, this ordering is accomplished via memory
> barriers.  But it is important to note that none of this matters
> for self-consistency, ...

Not logically from the view of the program's data-flow, but
physically - just to prevent any misapprehensions between us.

But you also didn't conceive what I described:
I assume a "fictious" acrhitecture (maybe there's a real architecture
which works like this) that has two kinds of read/write-barriers: one
that makes the thread self-consistent, i.e. the following reads would
see what previous instructions wrote to memory (I'm aware that this is
more complicated in real because of different behaviours of acquire-
and release-barriers); and one which makes that changes to memory be-
come visible to other CPUs. A "fictious" compiler (depending on whe-
ther there are architectures with this two consistency levels) which
would insert barriers of the first kind before calls to "foreign"
functions (i.e. functions whose effects on global variables can't be
observed at compilation-time) would require some explicit mechanisms
to force the thread to become consistent with other CPUs. So relying
on implicit barriers on those architectures wouldn't help to get
globally consistent.

.