Optimizations for mutable structures?

[Claus Reinke]

> Yup. this is exactly why C has the 'volatile' keyword. variables that
> are declared volatile will always be read and written to memory and
> never stored in a register because they could be modified by external
> interrupts or threads. If every varibale were considered volatile
> everything would be a whole whole lot slower. I have only had need to
> use it 3 times and all were in an operating system kernel.
> In any case, ghc IORefs are not 'volatile' in the C sense and that is a
> good thing.

but concurrent haskell (ch) is not c! in ch, you can adjust the scopes
of your variables so that scopes do not include other threads, so no
need for any slowdown - local variables are available for local 
optimisations. but when the scope of a variable does include
other threads, i for one do not want to go back to c/java-style efficiency
annotations as a means for code-obfuscation: if a variable is shared 
between threads, those threads should all see the same variable contents,
without me having to insert special synchronisation calls (or worse, 
wonder which operations might involve synchronisation and which
won't); if some variable's contents do not need to be seen by other 
threads, don't make that variable available to them.

scope extrusion/passing variables to other threads does not seem to 
be problematic, either: if thread A updates a variable passed to it by 
thread B, then those updates should be visible outside A.

but perhaps i am missing something? do you have any example in
mind where you'd actually need those extra annotations for efficiency?

cheers,
claus

ps does your later email imply that you suggest IORef/MVar as
    the non-volatile/volative separation? i'd rather see non-thread-
    local IORefs phased out of ch..