This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Heads-up: volatile and C++

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

"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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]