cvs commit: hugs98/lib/exts ConcBase.hs

[Alastair Reid]

reid        2001/04/20 17:18:30 PDT

  Modified files:
    lib/exts             ConcBase.hs 
  Log:
  2nd (and last) commit in this series.
  
  Added new MVar operations: tryTakeMVar and tryPutMVar.
  These have not been tested very thoroughly.
  
  We need one other change to make Hugs fully compatible with GHC: GHC
  recently(?) changed the behaviour of putMVar on a full variable.  This
  used to raise an exception but now it's supposed to block.  This is
  going to take a little pondering.  At the moment, an MVar is:
  
    newtype MVar a = MkMVar (IORef (Either a [a -> IOResult]))
  
  That is, it's either full or it's a (possibly empty) queue of blocked
  threads.  To accomodate the new semantics, it should change to
  something like:
  
    newtype MVar a = MkMVar (IORef (Either (a, [(a,IOResult)]) [a -> IOResult]))
  
  where
  
  Left (x, ts)
    represents a full mvar with a (possibly empty) list ts of
    blocked putters (and the values they want to put).
  
  Right ts
    represents an empty mvar with a (possibly empty) list ts
    which want to receive a value.
  
  Then we have to make putMVar block - with luck the mechanism used to
  block in takeMVar will work.
  
  And then we have to ponder the question of fairness:
  
  My original MVar implementation made no attempt to unblock threads in
  the same order as they had blocked.  In fact, they could be unblocked
  in exactly the opposite order from the order in which they had
  blocked.
  
  At the time, I argued that this was the correct behaviour since it was
  so manifestly unfair that no-one was going to be fooled into believing
  that Hugs' "scheduler" was fair.  I felt this was a good idea because
  it just wasn't possible to achieve fairness with a non-preemptive
  implementation and I'd rather have my code always fail than
  occasionally fail.
  
  But the moment my back was turned (:-)), the OGI folks made MVars
  fairer.  I imagine they much have had a reason to do this ...  Maybe I
  should preserve this fairness in the interest of not breaking
  anything.
  
  [Incidentally, a recent bug report on the ghc list suggests that
  ghc's MVars aren't fair either.  This code:
  
    forkIO (mapM_ putChar as) >> forkIO (mapM_ putChar bs)
     where as = 'a':as; bs = 'b':bs
  
  will output either all as or all bs.  It seems that 'mapM putChar as'
  spends almost all its time inside a mutex (protecting the stdout
  object) and that when 'mapM putChar bs' tries to acquire the same
  lock, it always fails.  The GHC folk are considering changing putMVar
  (I think) to consider preempting if there were any threads blocked on
  the mvar.
  ]
  
  Revision  Changes    Path
  1.6       +42 -1     hugs98/lib/exts/ConcBase.hs