I'm not sure I totally understand your question about 'unpacking' an MVar, but I'm going to assume you mean data structures that use the {-# UNPACK #-} pragma, like in Control.Concurrent.Future [1] and Control.Concurrent.NamedLock [2].

Here is how MVar is defined in GHC [3]:
    data MVar a = MVar (MVar# RealWorld a)

A "MVar# s a" is an unboxed pointer to a structure understood by the GHC runtime.

So yes, you can imagine a MVar as a pointer-to-pointer.  The structure it points at likely has another pointer to the embedded boxed "a", so it may even be pointer-to-pointer-to-pointer.

The MVar data structure exists to allow laziness; for example

   let x = unsafePerformIO (newMVar ()) in ()

is likely to not allocate an MVar#, just a thunk that would create an MVar if it was evaluated.  Unboxed objects (represented by convetion with # in GHC), on the other hand, are strict, so if you have an MVar# RealWorld (), you know it points to a valid MVar#.

From [2] we have
data NLItem = NLItem {-# UNPACK #-} !Int
                     {-# UNPACK #-} !(MVar ())

All the {-# UNPACK #-} pragma does is embed the contents of a strict single-constructor data declaration *directly* into the structure containing it; it's like you declared NLItem as such:

    data NLItem = NLItem Word# (MVar# RealWorld ())

except that if you call functions that want an Int or MVar thunk, the compiler will automatically re-box them in a new I#/MVar constructor.

Many copies of pointers to the same MVar# may exist; they are all 'identical' MVars; equality is defined as such:
    instance Eq (MVar a) where
            (MVar mvar1#) == (MVar mvar2#) = sameMVar# mvar1# mvar2#

where sameMVar# is a primitive that is probably just raw pointer equality.

Because of this, boxed MVars can be garbage collected without necessarily garbage-collecting the MVar# it holds, if a live reference to that MVar# still exists elsewhere.

  -- ryan

[1] http://hackage.haskell.org/packages/archive/future/2.0.0/doc/html/src/Control-Concurrent-Future.html
[2] http://hackage.haskell.org/packages/archive/named-lock/0.1/doc/html/src/Control-Concurrent-NamedLock.html
[3] http://www.haskell.org/ghc/docs/7.4.1/html/libraries/base/src/GHC-MVar.html#MVar

On Mon, Jul 30, 2012 at 9:25 PM, Leon Smith <leon.p.smith@gmail.com> wrote:
I admit I don't know exactly how MVars are implemented,  but given that they can be aliased and have indefinite extent,   I would think that they look something vaguely like a  cdatatype ** var,  basically a pointer to an MVar (which is itself a pointer,  modulo some other things such as a thread queue.)

And,  I would think that "unpacking" such an structure would basically be eliminating one layer of indirection,  so it would then look vague like a cdatatype * var.    But again,  given aliasing and indefinite extent, this would seem to be a difficult thing to do.

Actually this isn't too difficult if an MVar only exists in a single unpacked structure:   other references to the MVar can simply be pointers into the structure.   But the case where an MVar is unpacked into two different structures suggests that,  at least in some cases,  an "unpacked" MVar is still a cdatatype ** var;

So, is my understanding more or less correct?  Does anybody have a good, succinct explanation of how MVars are implemented,  and how they are unpacked?

One final question,   assuming that unpacking an MVar really does eliminate a layer of indirection,  and that other references to that MVar are simply pointers into a larger structure,   what happens to that larger structure when there are no more references to it (but still some references to the MVar?)    Given the complications that must arise out of a doubly "unpacked" MVar,  I'm going to guess that the larger structure does get garbage collected in this case,  and that the MVar becomes dislodged from this structure.   Would that MVar then be placed directly inside another unpacked reference, if one is available?

Best,
Leon

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe