Re: Optimizations for mutable structures?

[previously sent by mistake to Simon only - new para at end]
"Simon Marlow"
Now, take the original program, but change the creation of m2 to "newMVar ()", i.e. m2 starts off full. Is the transformation valid now? Well maybe, because in some interleavings acts does not block, and we can prove that at compilation time.
I don't think it is valid for a compiler to say that "one possible execution path permits me to remove some code, therefore I will remove that code on all possible execution paths". The example I had in mind was a GUI where the action writeIORef r e >> acts >> readIORef r is intended to capture a situation where first we record some global configuration data for the application, then permit some arbitrary GUI actions to occur, and then we retrieve the configuration data again. My expectation is that the config data /will/ have been changed by some other GUI thread. Surely it cannot be OK for the compiler to silently deliver the original unchanged data here - it goes against the programmer's intention. Surely, if a Haskell programmer is going to write code that explicitly reads from a reference after writing to it, that sequence must 9/10 be intentional: otherwise wouldn't she have just used a let-binding? Regards, Malcolm

On Wed, Dec 07, 2005 at 05:36:09PM +0000, Malcolm Wallace wrote:
My expectation is that the config data /will/ have been changed by some other GUI thread. Surely it cannot be OK for the compiler to silently deliver the original unchanged data here - it goes against the programmer's intention.
then you should be using MVars. I don't think ghc guarentees (except by accident of implementation) anything about using IORefs from multiple threads and you shouldn't count on code which does so working in the future. At least it shouldn't, since thread synchronization is a very expensive thing compared to direct memory access and registers. this is something of an argument for providing MVars or some thread-safe version of IORefs with all haskell implementations whether they have concurrency or not so people can write portable thread-safe libraries that don't actually use concurrency themselves. John -- John Meacham - ⑆repetae.net⑆john⑈
participants (2)
-
John Meacham
-
Malcolm Wallace