Subj : Re: Memory Barriers, Compiler Optimizations, etc.
To   : comp.programming.threads
From : Scott Meyers
Date : Thu Feb 03 2005 07:37 pm

On Thu, 03 Feb 2005 13:47:08 -0500, Joseph Seigh wrote:
> I guess.  I'm not real familiar with volatile since it's not that useful
> in threading.  If expressions are sequence points then that should make
> every statement a sequence point also.

There is a sequence point at the end of each statement, but that doesn't
help any for purposes of ordering reads and writes, because sequence points
constrain only observable behavior, and reads and write to nonvolatile data
are not considered observable by the C++ standard.  This is actually a
feature.  Without it, you can't do things like hoist loop-invariant
computations out of loops, do common subexpression elimination, etc.  I
mean, really, as a general rule, you do NOT want to execute the code the
programmer actually wrote, because it's fairly awful, from a performance
point of view.  In general :-)

From my perspective, there are two problems for C/C++ programmers:
  - How do we keep compilers from ordering our reads/write in a way
    contrary to what we want to be present in the generated code (i.e.,
    "program order")?
  - How do we make sure that the reads/writes that take place during
    execution are made visible to other threads in the order in which they
    take place in our thread?
If compilers recognize memory barriers, memory barriers solve both
problems.  If compilers do not recognize them, we may need more than memory
barriers, e.g., volatile.

> > However, if compilers recognize and respect the semantics of membars, the
> > need for volatile goes away, because I can just stick a membar between the
> > reads (which I need anyway), and the problem is solved.
> 
> AFAIK they don't, so we have to use the ad hoc solutions that we use
> now.

Oh, goody.

> It sort of the same for separately compiled external functions.  You
> assume that the compiler has to drop optimization for any variable that
> has had its address gotten from or passed to an external routine, or has
> the external attribute.  It could break at some point and we'll have to
> start writing all the synchronization functions in external assembler
> programs.  That will make memory barriers more expensive than they
> already are.

It seems clear to me that we need a way to communicate with compilers so
that they know the constraints we want to impose.  They can either
recognize the signifcance of certain constructs (e.g., my understanding is
that compilers compliant with Posix threads must not optimize across
certain library calls) or we can add pragmas or something.    Then again, I
could be completely off base here.  I'm new to this stuff.

Scott

.