On 24 Apr 2008, at 12:02, apfelmus wrote:
Sounds good. But I wonder what obscure optimization comes next;
can we have a toy-model of STM? I mean, it should be possible to
express both the continuation-logging and read-only-fail
optimization in terms of
type STM a = Maybe a
or similar?
David Roundy wrote:
A simple primitive to do this (in combination with a totally
rewritten STM runtime) would be
subatomically :: ReadOnlySTM a - STM ()
which would run a STM computation that is guaranteed to have no
side-effects (i.e. can't write to TVars) and ignore its results (and
let
Ryan Ingram wrote:
No spooky-action-at-a-distance is possible. David's more general
subatomically primitive would achieve the same results; the proof is
that
(1) no side effects can be caused by the subatomic action, that is, no
writes happen which could change future reads.
(2) the result of
On Thu, 24 Apr 2008 12:57:56 +0200, apfelmus wrote:
there is also the option of collapsing ReadOnlySTM a and STM a
by changing the semantics of writeTVar .
I mean, writeTVar can be used for two different things:
1) communicate with other threads, i.e. crossing
atomically
Chris Smith wrote:
apfelmus wrote:
For 1), it's enough to have a primitive
scheduleWriteTVar :: TVar a - a - STM ()
that ensures to write the TVar at the very end of the atomically block..
Unfortunately, though, this breaks the very thing that makes STM
attractive: namely,
On Wed, 23 Apr 2008 15:54:15 +0100, Tim Harris (RESEARCH) wrote:
What do you think about a slight change:
readTVarWhen :: TVar a - (a - bool) - STM a
This would retry until the (a-bool) function returns true (and, of
course, as with a normal retry, the implementation would need to watch
Ryan Ingram wrote:
Consider the following transaction:
intV :: TVar Int
boolV :: TVar Bool
interesting = atomically $ do
retryUntil intV ( 50)
retryUntil boolV id
Lets say that intV contains 100 and boolV contains False. Then this
transaction retries. Now, if intV changes to 101,
On 4/23/08, apfelmus [EMAIL PROTECTED] wrote:
I don't quite understand what you want to do but I presume it's related to
the following: given an expression like
readTVar intV = (\ - ... readTVar boolV = (\_ - ... retry))
The ... indicate branches that are there have not been taken in our
On Tue, 22 Apr 2008 14:48:54 -0700, Ryan Ingram wrote:
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 is still
less than t0.
On 4/22/08, Chris Smith [EMAIL PROTECTED] wrote:
One primitive that would be strong enough is this: retryUntil :: TVar a
- (a - Bool) - STM ()
Hmm. This makes me suspicious. A change to a variable may change the
transaction such that it never even calls your retryUntil the next time
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
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
12 matches
Mail list logo
