Re: Heads-up: volatile and C++

["Michael N. Moran" <mike at mnmoran dot org>]

Jason Merrill wrote:
> The C++ committee (well, a subgroup represented at this meeting by Hans
> Boehm) is working on a memory model that supports threaded programs.  

As someone who uses the C++ language and multi-threading
extensively in embedded systems, I have come to the following
belief/opinion.

  The language (C++) *should not* have dependencies
  upon threading. IMHO, threading is a layer above a
  systems programming language, and having dependencies
  upon upper layers is evil.

> One
> proposed change is to the semantics of volatile. 

Since IANALL, but I believe (as obviously you do)
that changing the semantics of volatile should be
under-taken with great care.

I'm not familiar with ia64 barrier instructions, but I
*am* familiar with PowerPC barrier and synchronization
instructions (eieio, sync, isync, etc.), and I would
question the practice of automatically generating
these as side effect of a variable being declared
as volatile, if for no other reason than the possible
presence of code that is unnecessary in some (perhaps
most) circumstances.

If the committee believes that the language needs
support for barriers, then I believe it would be
better to use a different approach. For example:

o barrier keyword(s)
o barrier qualifier(s)

<off topic>
While I'm on my soap-box ...
I would like to see some sort of alignment qualifiers
added to the C++ language for those of us that need
to deal with directly with page/cache alignment
(for both types and objects.)
</off topic>

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
 and we never even know we have the key."
The Eagles, "Already Gone"

The Beatles were wrong: 1 & 1 & 1 is 1