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
