> if (!initialized) {
> set a bunch of fields
> }
> read a bunch of fields
>
> Right now, if initialized isn't volatile, this is badly broken. But
> under the old semantics, this is broken even if you declare
> initialized to be volatile, because memory operations on volatile and
> nonvolatile variables can be freely reordered.
>
> I propose changing the semantics so that before writing to a volatile
> variable, you must flush all writes from registers and cache (a
> "release") and after reading a volatile variable, you must update
> registers and cache (an "acquire").
I'm having a hard time understanding why you want to introduce
exceptional semantics to handle broken code, at least without
any argument about why it shouldn't be considered broken.
Here, forcing volatile to work this way might make it heavier than
necessary when used in its common legitimate contexts.
Consider instead saying that volatiles are just like regular variables
except that they are their own monitors. And that read causes
acquire, but without (necessarily) any locking action, etc.
-Doug
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:21 EDT