Heads-up: volatile and C++

[Michael N. Moran]

Paul Schlie wrote:
>>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?)
> 

I'm not certain I understand what you are proposing, other than
there being some difference connection between how objects are
declared (their scope) and the semantics attached with uses of
the object.

What happens to volatile pointers/references passed through
functions? Which "semantic" would be emitted by the compiler when
these are dereferenced?

Even without a thorough understanding, on the surface,
this seems ... unintuitive.

> 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.

I guess that the reason adding new keywords is a problem is its
interaction with existing C++ code? Sorry, I'm not an expert.

-- 
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