Optimizations for mutable structures?
claus.reinke at talk21.com
Wed Dec 7 19:17:36 EST 2005
> 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?
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..
More information about the Glasgow-haskell-users