RE: [boost] RFC: Multithreading design constraints

From: Bill Wade (bill.wade_at_[hidden])
Date: 2000-06-08 10:02:46

> Can we assume a compiler (which may be multi-platform, like
> Metrowerks or egcs) treats operating system function calls like
> "library I/O functions"?  That seems risky.  Volatile seems a safer
> way to force sequence, at least based on that one sentence in the
> standard.

Volatile is safer, but it can be very inconvenient.  Suppose I want to
synchronize access to some particular std::vector (say look at its size()).

If I make the vector volatile I can't use it for much of anything, since
vector has no volatile members.

If I don't make the vector volatile, a conforming, optimizing compiler just
might manage to move my vector operations outside of my synchronization
code.

If I make the vector volatile but cast-away its volatileness, I get
undefined behavior.

If I make the vector non-volatile but access it through a volatile reference
(and then cast-away the volatile) my head starts to spin.

In practice it would seem that I need to either
  1) Write my own vector class with a volatile size() member.
  2) Count on the compiler recognizing that calls to synchronization
primitives imply MT.
  3) Make it impractical for the compiler to perform the optimization.
  4) Count on the undefined behavior associated with casting away volatile
as being benign.