Should we have primitive fill-once variables?

[Oleg Grenrus]

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