Heads-up: volatile and C++

[Paul Schlie]

> Michael N. Moran wrote:
> I'm very much in favor of fine grained synchronization primitives
> in the compiler, but not of changes to volatile semantics.

I wonder if it would be sufficient (if not preferable) to only extend
(modify) the semantics for heap/stack and const volatile variables, as
enforcing existing volatile semantics for such variables are at best
of questionable existing value. i.e.:

 volatile vv;        // volatile sync primitive, w/normal access semantics.
 volatile const vc;  // universal sync primitive, w/normal access semantics.
 volatile *vp = <some-address>;  // a true volatile reference.

 vv; // volatile sync, all pending volatile transactions logically emitted
     // into the code, but not hard physically synchronized via a HW sync.

 vc; // universal sync, all pending transactions hard physically sync'ed.

 *vp = <some-value>; // volatile access semantics enforced, with ordering
                     // warranted between equivalent references, but not
                     // otherwise (unless synchronized by referencing a
                     // declared or (cast) volatile sync variable).

(with the exception of new sync semantics, non-reference volatile variables
 do not need to have volatile access semantics, as it would seem to serve
 no useful purpose for stack/heap allocated variables, and should be allowed
 to be optimized always just as for any other allocated variable; although
 their sync, semantic actions must be preserved, thereby may still be used
 as synchronized value semaphores, etc, or as simply sync's when no access
 would otherwise be required; and/or allow regular variables to be cast as
 (volatile), thereby enabling a arbitrary expression to insert a sync, i.e.:
 (volatile)x = y, or x = (const volatile)y; forcing a specified sync prior
 to, or after the assignment?)

Where the above is just expressed as a loose possible alternative to
strictly enforcing ordering between all volatile or otherwise transactions
without having to necessarily introduce another keyword, for good or bad.