> broken2 = atomically $ do
> (v1, v2) <- expensive_computation :: STM (TVar Int, TVar Int)
> retryUntil v1 (> 50)
> x <- expensive_computation2 :: STM Int
> retryUntil v2 (> x)
Ah. I think I see now. I had thought you were trying to give more power to
the primitive than you are.
But I'm
I said:
> In that case, we can treat subatomic as a "hint" to the STM runtime. It
> could have a simpler type, and the semantics of "id":
>
> subatomic :: STM a -> STM a
>
> If the subatomic transaction turns out to be read-only, then we get the
> benefit of all four cases Ryan describes above. I
Ryan Ingram said:
> So, if have a transaction T that is waiting inside "retry" for a
> variable that it read to change, and a variable that is only accessed
> in a "subatomic" part of T is changed, we can try running the
> subatomic computation first. Here are the four cases:
>
> 1) The subatomic
On 4/23/08, Sterling Clover <[EMAIL PROTECTED]> wrote:
> But expensive_computation2 is in STM. This means that it *should* be rerun,
> no? Between the first run and the retry, the result of
> expensive_computation2 may well have changed.
Ah, but that's not true; the main "good thing" about retry i
-- non-primitive retryUntil:
retryUntil v p = do
x <- readVar v
unless (p x) retry
broken2 = atomically $ do
(v1, v2) <- expensive_computation :: STM (TVar Int, TVar Int)
retryUntil v1 (> 50)
x <- expensive_computation2 :: STM Int
retryUntil v2 (> x)
If v1 succeeds and v2 fail
On Wed, Apr 23, 2008 at 01:46:53PM -0700, Ryan Ingram wrote:
> On 4/23/08, David Roundy <[EMAIL PROTECTED]> wrote:
> > I'm confused as to how your retryUntil gains you anything. If any of the
> > TVars used in the expensive_computation change while waiting for a retry,
> > then the expensive_compu
On 4/23/08, David Roundy <[EMAIL PROTECTED]> wrote:
> I'm confused as to how your retryUntil gains you anything. If any of the
> TVars used in the expensive_computation change while waiting for a retry,
> then the expensive_computation will need to be done again. If none of them
> change, then we
On Wed, Apr 23, 2008 at 12:12:15PM -0700, Ryan Ingram wrote:
> On 4/23/08, Jan-Willem Maessen <[EMAIL PROTECTED]> wrote:
> > I've been trying to decide whether either of these is implementable in terms
> > of `orElse`, in such a way that we immediately check the predicate upon
> > retry before doin
On 4/23/08, Jan-Willem Maessen <[EMAIL PROTECTED]> wrote:
> I've been trying to decide whether either of these is implementable in terms
> of `orElse`, in such a way that we immediately check the predicate upon
> retry before doing anything else. I can't quite make up my mind whether
> this is po
On Apr 23, 2008, at 12:13 PM, Ryan Ingram wrote:
On Wed, Apr 23, 2008 at 7:54 AM, Tim Harris (RESEARCH)
<[EMAIL PROTECTED]> wrote:
What do you think about a slight change:
readTVarWhen :: TVar a -> (a -> bool) -> STM a
This seems strictly less powerful than retryUntil:
readTVarWhen v p =
On Wed, Apr 23, 2008 at 7:54 AM, Tim Harris (RESEARCH)
<[EMAIL PROTECTED]> wrote:
> What do you think about a slight change:
>
>readTVarWhen :: TVar a -> (a -> bool) -> STM a
This seems strictly less powerful than retryUntil:
> readTVarWhen v p = retryUntil v p >> readTVar v
Consider the fol
l Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ryan Ingram
Sent: 22 April 2008 14:49
To: haskell-cafe@haskell.org
Subject: [Haskell-cafe] Stronger STM primitives needed? Or am I just doing it
wrong?
How can I implement the following operation efficiently in STM? Given
Ryan Ingram said:
> How can I implement the following operation efficiently in STM? Given
> a TVar "now",
>
> waitFor t0 = do
> t <- readTVar now
> if (t < t0) then retry else return ()
>
> This naive implementation has the problem that the transaction gets
> restarted every time "now" g
How can I implement the following operation efficiently in STM? Given
a TVar "now",
waitFor t0 = do
t <- readTVar now
if (t < t0) then retry else return ()
This naive implementation has the problem that the transaction gets
restarted every time "now" gets updated, even if the new value i
14 matches
Mail list logo
