This is the mail archive of the
mailing list for the GCC project.
Re: Heads-up: volatile and C++
- From: Paul Schlie <schlie at comcast dot net>
- To: "Michael N. Moran" <mike at mnmoran dot org>
- Cc: Jason Merrill <jason at redhat dot com>,Paul Koning <pkoning at equallogic dot com>,<gcc at gcc dot gnu dot org>
- Date: Fri, 15 Apr 2005 12:22:33 -0400
- Subject: Re: Heads-up: volatile and C++
> 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.