Should we have primitive fill-once variables?

[Ryan Trinkle]

This would make MonadFix's implementation much nicer, I think :)

On Fri, Jun 29, 2018 at 9:14 AM, Oleg Grenrus <oleg.grenrus at iki.fi> wrote:

> I have wanted something like that! Also similiar STM TQVar would be nice
> to have. For example `async` uses TMVar where the value is written only
> once. if once filled the QVar cannot be empty is useful property.
>
> For STM variant, I'd actually like to have
>
> putTQVar' :: QTVar a -> a -> STM (TVar a)
>
> i.e. giving me back a `TVar a`, for which I now the value is already
> there (i.e. reading won't block). Not sure what the would be such for
> IO, IORef doesn't feel right.
>
> - Oleg
>
> On 29.06.2018 08:28, David Feuer wrote:
> > IVars (write-once variables) can be useful for various purposes. In
> Haskell, they can be implemented using MVars. But MVars are not the
> lightest things in the world. I'm wondering if it might pay to implement
> something much lighter primitively. Here's a sketch of some things I'll
> tentatively call QVars.
> >
> > A QVar has two fields: a value (possibly null) and a stack (no need for
> a queue) of waiting threads.
> >
> > newEmptyQVar: Create a QVar with a null value and an empty queue.
> >
> > tryReadQVar: Just look at the value.
> >
> > readQVar: Check if the value is null (simple memory read). If not, use
> it. If so, push yourself onto the waiting stack (CAS loop). The code that
> will run when you're awakened will try to awaken the next thread if there
> is one (CAS loop).
> >
> > putQVar: Install a new value and get the old one (exchange). If the old
> value was null, mark the QVar dirty. Awaken the first thread if there is
> one (CAS loop). Return the old value if it was non-null (this can be used
> in library code to make duplicate writes, or non-equal duplicate writes, an
> error).
> >
> > I think we'd probably also want atomic modification operations, but I
> haven't figured out which ones yet.
> >
> > Implementation differences from MVars:
> >
> > * We have two fields instead of three (because we can get away with a
> stack instead of a queue).
> >
> > * We never need to lock the QVar closure. MVars do: they can change
> freely between empty and full, so it's necessary to coordinate between
> value and queue modifications.
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20180629/867dd07c/attachment.html>