[Haskell-cafe] IORef memory leak

[Thomas Schilling]

Correct, here's a video of Simon explaining the thunk blackholing
issue and its solution in GHC 7:

http://vimeo.com/15573590

On 15 October 2010 21:31, Gregory Collins <greg at gregorycollins.net> wrote:
> Evan Laforge <qdunkan at gmail.com> writes:
>
>> The only workaround I could find is to immediately read the value back
>> out and 'seq' on it, but it's ugly.
>
> Yep! C'est la vie unfortunately.
>
> The way atomicModifyIORef works is that the new value isn't actually
> evaluated at all; GHC just swaps the old value with a thunk which will
> do the modification when the value is demanded.
>
> It's done like that so that the atomic modification can be done with a
> compare-and-swap CPU instruction; a fully-fledged lock would have to be
> taken otherwise, because your function could do an unbounded amount of
> work. While that's happening, other mutator threads could be writing
> into your memory cell, having read the same old value you did, and then
> *splat*, the souffle is ruined.
>
> Once you're taking a lock, you've got yourself an MVar. This is why
> IORefs are generally (always?) faster than MVars under contention; the
> lighter-weight lock mechanism means mutator threads don't block, if the
> CAS fails atomicModifyIORef just tries again in a busy loop. (I think!)
>
> Of course, the mutator threads themselves then tend to bump into each
> other or do redundant work when it's time to evaluate the thunks (GHC
> tries to avoid this using "thunk blackholing"). Contention issues here
> have gotten radically better in recent versions of GHC I think.
>
> Forgive me if I've gotten anything wrong here, I think Simon Marlow
> might be the only person who *really* understands how all this stuff
> works. :)
>
>
>> So two questions:
>>
>> writeIORef doesn't have this problem.  If I am just writing a simple
>> value, is writeIORef atomic?  In other words, can I replace
>> 'atomicModifyIORef r (const (x, ())' with 'writeIORef r x'?
>>
>> Any reason to not do solution 1 above?
>
> Well if you're not inspecting or using the old value then it's safe to
> just blow it away, yes.
>
> Cheers,
>
> G
> --
> Gregory Collins <greg at gregorycollins.net>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
Push the envelope. Watch it bend.