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..