This would make MonadFix's implementation much nicer, I think :)
On Fri, Jun 29, 2018 at 9:14 AM, 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
IVars (write-once variables) can be useful for various purposes. In Haskell, they can be implemented using MVars. But MVars are not the
On 29.06.2018 08:28, David Feuer wrote: 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs