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