> From: Paul Koning <[EMAIL PROTECTED]> >>>>>> "Paul" == Paul Schlie <[EMAIL PROTECTED]> writes: > >>> 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. > > Paul> I wonder if it would be sufficient (if not preferable) to only > Paul> extend (modify) the semantics for heap/stack and const volatile > Paul> variables, as enforcing existing volatile semantics for such > Paul> variables are at best of questionable existing value.... > > I'm not sure I completely understand, but volatile heap variables are > perfectly meaningful today. For example, if I need to define a > communication data area for the program to talk to some DMA I/O > device, a volatile struct, or a struct some of whose members are > volatile, allocated on the heap, makes perfect sense.
- yes, but only if through a reference it would seem, as otherwise a volatile object couldn't be modifiable by anything outside of the program itself. But acknowledge that this would require an allocated volatile's semantics be dependant on potential references to it being declared, which is likely too messy to be worthy of any consideration.
