|>> - Fetch elimination for imperative reads: |>> writeIORef r e >> acts >> readIORef r |>> === writeIORef r e >> acts >> return e |> |> This transformation is valid only on single-threaded systems. |> If there is any possibility of an IORef being shared across threads, |> you are out of luck. | |(assuming 'acts' doesn't modify 'r').
this remark is the problem. |No, Jan's transformation is correct even in a multithreaded setting. It |might eliminate some possible outcomes from a non-deterministic program, |but that's ok. There's no requirement that all interleavings according |to the semantics have to be implemented. .. not implementing traces promised as possible by the semantics is not a good idea, imho, as programmers have some control over the set of traces themselves. in this case, acts could implement the synchronisation with another thread working on r, ie., even if acts does not modify r itself, it might reliably cause another thread to modify r before acts can end. if such synchronisations depend on traces you have eliminated, the code would just block (without apparent reason), whereas in this case, r will have a value after acts that shouldn't have been possible, due to the explicit synchronisation code (again, happy debugging) .. of course, you could try to infer non-sequential interference with r resulting from act, but that is what Malcolm pointed out - you have to take the full semantics into account when doing such transformations (btw, java originally made a mess of this- hope that has been fixed by now). cheers, claus _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
