[Haskell-cafe] Re: Stronger STM primitives needed? Or am I just doing it wrong?

[Ryan Ingram]

Actually, I think I came up with a solution on the way home from work
today.  Instead of

> data Future t a = Fut
>     { waitFor :: t -> STM ()
>     , value :: STM (t, a)
>     }

I will use

> data Future t a = Fut
>     { waitFor :: t -> IO (STM ())
>     , value :: IO (STM (t, a))
>     }

The goal is to be able to wait on multiple things at a time, but that
doesn't mean all the setup has to happen in STM.  Now I can setup some
TVars in IO and then hand-off to STM for the niceness of "orElse".

   -- ryan

On Tue, Apr 22, 2008 at 6:46 PM, Matthew Brecknell
<haskell at brecknell.org> wrote:
> Ryan Ingram said:
>  >
>  > retryUntil :: TVar a -> (a -> Bool) -> STM ()
>  >
>  > [...]
>
> >
>  > the semantics would be that the transaction log,
>  > instead of saying "I read from v" would say "I read from v and failed
>  > because v didn't satisfy this predicate".
>  >
>  > Changes to any other variable in the log would have the same effect as
>  > always: restarting the transaction.  This is actually required in my
>  > desired use case; I want to block until "now" becomes >= t, or a
>  > different TVar gets filled with a non-Nothing value.
>
>  I see now what you mean, and I can see that it might be a nice little
>  addition. By giving the STM runtime additional information about what
>  conditions would allow the transaction to progress, it might be able to
>  save some false retries. Note that the only work that is saved is the
>  work done to get to the retryUntil.
>
>  However, strictly speaking, the STM runtime doesn't need this additional
>  information. You could view a composite STM transaction as an inverted
>  tree, with individual reads at the leaves, merging through monadic
>  bindings towards the root, which is the final result (which includes the
>  transaction's atomic updates). A transaction waiting on a retry is just
>  one of these trees in suspended animation, waiting for a new value to be
>  written to one of the leaves. When such a value is written to one of the
>  leaves, only its downstream nodes need re-evaluation.
>
>  Implementing STM that way may not be worth the effort, though, whereas
>  retryUntil might be.
>
>
>
>  _______________________________________________
>  Haskell-Cafe mailing list
>  Haskell-Cafe at haskell.org
>  http://www.haskell.org/mailman/listinfo/haskell-cafe
>