A ticket is fine. If someone wants to dig into it further, please feel free
to add info to the ticket.
On Thursday, March 9, 2017 at 9:07:31 AM UTC-6, Bendlas wrote:
>
> 2017-03-09 12:34 GMT+01:00 'bertschi' via Clojure <
> clojure@googlegroups.com>:
> > Thanks for your comments. As suggested I
Thanks for your comments. As suggested I ran a small benchmark of both
versions. Turns out that the difference between (ref-set ref @ref) and
ensure is huge ...
(defn write-skew [de-ref]
(let [cats (ref 1)
dogs (ref 1)
john (future
(dosync
(when
2017-03-06 12:06 GMT+01:00 'bertschi' via Clojure :
> From the docs it says "Allows for more concurrency than (ref-set ref @ref)".
> I would read that as "runs at least as fast as (ref-set ref @ref)", but
> using (ref-set dogs @dogs) instead of (ensure dogs) and the same with cats,
> does not exhi
https://clojuredocs.org/clojure.core/ensure
Must be called in a transaction. Protects the ref from modification
by other transactions. Returns the in-transaction-value of
ref. Allows for more concurrency than (ref-set ref @ref)
This can be read in two contradictory ways. Protecting a ref dur
On Mon, Mar 15, 2010 at 3:34 PM, Raoul Duke wrote:
> On Mon, Mar 15, 2010 at 1:13 AM, Christophe Grand
> wrote:
>> It hasn't blocked in the sense of "wait and continue": it retries the
>> transaction after growing the history of the ref (refs have an adaptive
>> history):
>
> i'm confused about
On Mon, Mar 15, 2010 at 1:13 AM, Christophe Grand wrote:
> It hasn't blocked in the sense of "wait and continue": it retries the
> transaction after growing the history of the ref (refs have an adaptive
> history):
i'm confused about being able to set :max-history, does that not run
the risk of b
hi Mark,
On Mon, Mar 15, 2010 at 2:16 AM, Mark Engelberg
wrote:
> Wow, the STM works far, far differently than I imagined, but I think I get
> it now. The adaptive history clarification helped tremendously. Thanks,
per chance, might you be willing/able to summarize the latest mental
model you
On 15 March 2010 08:44, Mark Engelberg wrote:
> Thanks Michal, those annotations helped quite a bit.
You're welcome!
> It also demonstrates
> to me that my mental model of how the STM works is quite out of touch with
> how it actually does.
I rather think I'm in that situation myself. Take the
On 15 March 2010 09:13, Christophe Grand wrote:
> It hasn't blocked in the sense of "wait and continue": it retries the
> transaction after growing the history of the ref (refs have an adaptive
> history):
Thanks a bunch for pointing this one out! I sort of recall reading
ref's docs and not reall
Wow, the STM works far, far differently than I imagined, but I think I get
it now. The adaptive history clarification helped tremendously. Thanks,
Mark
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@goo
On Mon, Mar 15, 2010 at 8:44 AM, Mark Engelberg wrote:
> Thanks Michal, those annotations helped quite a bit. It also demonstrates
> to me that my mental model of how the STM works is quite out of touch with
> how it actually does.
>
> I'm especially surprised that derefs work the way your exampl
Thanks Michal, those annotations helped quite a bit. It also demonstrates
to me that my mental model of how the STM works is quite out of touch with
how it actually does.
I'm especially surprised that derefs work the way your example illustrates.
>From the STM docs, it really sounded like derefs
2010/3/15 Mark Engelberg :
> Michal, aren't those examples backwards? I would expect the ensure version
> to be the one that needs to retry, and the deref version to be the one that
> doesn't.
Oh, I failed to notice this message, sorry... I've answered your reply
to Meikel first. Anyway, here's a
On 15 March 2010 08:07, Mark Engelberg wrote:
> So what I'm finally realizing is that although you are guaranteed a
> consistent read value throughout the transaction, that value might become
> out of touch with "reality" unless you use ensure.
That's not true actually. For example:
user> (def r
2010/3/14 Meikel Brandmeyer
> In short: ensure is used when you require only read access to a Ref,
> but need the value to be constant through the transaction. If you
> modify the a Ref via alter or ref-set, the ensure is not necessary.
>
>
OK, I think I've finally figured out why I've always fou
Michal, aren't those examples backwards? I would expect the ensure version
to be the one that needs to retry, and the deref version to be the one that
doesn't.
2010/3/14 Michał Marczyk
> On 15 March 2010 06:47, Mark Engelberg wrote:
> > What's a minimal example that demonstrates when ensure is
Hi,
On Mar 15, 6:47 am, Mark Engelberg wrote:
> What's a minimal example that demonstrates when ensure is necessary?
Ok. Maybe a little grotesque and not 100% valid, but it should get
across the idea.
(dosync
(when (= @reactor-state :off)
(alter reactor-door open)))
Once every 100 years
On 15 March 2010 06:47, Mark Engelberg wrote:
> What's a minimal example that demonstrates when ensure is necessary?
Here's a link to my posting to an earlier thread with a minimal
example of how ensure is different from deref:
http://groups.google.com/group/clojure/msg/8e477df4b5cf418e
Is this
It prevents write skew when you wish to use a non-modified ref as a
condition for the transaction to proceed.
Here's a nice description:
http://clojure.higher-order.net/2009/09/the-write-skew-anomaly/
On Sep 29, 10:32 pm, Volkan YAZICI wrote:
> Hi,
>
> Can anybody give an example to the usage
On Thu, Sep 17, 2009 at 1:09 PM, John Harrop wrote:
> Don't commutes commute with one another, but not with other writes?
That's certainly correct from the standpoint of thinking about how
commutes get reexecuted during the commit and other writes (from
ref-set and alter) do not.
Here is how I
Don't commutes commute with one another, but not with other writes?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from ne
On Thu, Sep 17, 2009 at 1:25 PM, Mark Volkmann
wrote:
>
> On Thu, Sep 17, 2009 at 11:12 AM, John Harrop wrote:
>>
>> Not with ref-set! or alter!, but maybe with commute identity?
>
> I should have been more clear above. What I meant was that multiple
> concurrent transactions cannot write the sa
On Thu, Sep 17, 2009 at 11:12 AM, John Harrop wrote:
> On Thu, Sep 17, 2009 at 11:04 AM, Mark Volkmann
> wrote:
>>
>> On Thu, Sep 17, 2009 at 9:57 AM, Chouser wrote:
>> >
>> > On Thu, Sep 17, 2009 at 12:28 AM, Krukow wrote:
>> >>
>> >> Final question. The docs say that 'ensure' permits more co
On Thu, Sep 17, 2009 at 11:04 AM, Mark Volkmann
wrote:
> On Thu, Sep 17, 2009 at 9:57 AM, Chouser wrote:
> >
> > On Thu, Sep 17, 2009 at 12:28 AM, Krukow wrote:
> >>
> >> Final question. The docs say that 'ensure' permits more concurrency
> >> than promoting the ref to a write. Is there a quick/
On Thu, Sep 17, 2009 at 12:28 AM, Krukow wrote:
>
> Final question. The docs say that 'ensure' permits more concurrency
> than promoting the ref to a write. Is there a quick/simple way of
> explaining how? (Or do I need to go to the source :-)
If you have multiple transactions ensuring the same
On Thu, Sep 17, 2009 at 9:57 AM, Chouser wrote:
>
> On Thu, Sep 17, 2009 at 12:28 AM, Krukow wrote:
>>
>> Final question. The docs say that 'ensure' permits more concurrency
>> than promoting the ref to a write. Is there a quick/simple way of
>> explaining how? (Or do I need to go to the source
On Wed, Sep 16, 2009 at 11:28 PM, Krukow wrote:
>
> Final question. The docs say that 'ensure' permits more concurrency
> than promoting the ref to a write. Is there a quick/simple way of
> explaining how? (Or do I need to go to the source :-)
When you call ensure on a Ref, the current LockingTr
On Thu, Sep 17, 2009 at 6:28 AM, Krukow wrote:
>
>
>
> On Sep 16, 10:06 pm, Rich Hickey wrote:
>> On Sep 16, 11:39 am, Stuart Halloway
>> wrote:
>>
>> > The docs could be more clear, but if validate-fn must be side effect
>> > free then it certainly can't look at any other refs.
>>
>> Yes. The
On Sep 16, 10:06 pm, Rich Hickey wrote:
> On Sep 16, 11:39 am, Stuart Halloway
> wrote:
>
> > The docs could be more clear, but if validate-fn must be side effect
> > free then it certainly can't look at any other refs.
>
> Yes. The docs should say the function must be pure. While I understa
On Sep 16, 11:39 am, Stuart Halloway
wrote:
> The docs could be more clear, but if validate-fn must be side effect
> free then it certainly can't look at any other refs.
>
Yes. The docs should say the function must be pure. While I understand
the multi-ref validation use case, currently it i
The docs could be more clear, but if validate-fn must be side effect
free then it certainly can't look at any other refs.
Stu
> On Sep 16, 11:15 am, Christophe Grand wrote:
>> I think you managed to produce a deadlock :-(
>>
>> thread 1 is commiting and has a write lock on a1
>> thread 2 is c
On Sep 16, 11:15 am, Christophe Grand wrote:
> I think you managed to produce a deadlock :-(
>
> thread 1 is commiting and has a write lock on a1
> thread 2 is commiting and has a write lock on a2
> thread1 tries to acquire a read lock on a2 (in the validator) and blocks
> because thread2 has a
On Wed, Sep 16, 2009 at 6:34 AM, Krukow wrote:
> Another interesting thing happened. I wrote another program using ref
> validators only.
>
> http://paste.lisp.org/display/87117#4
>
> That program does produce write-skews. Further, occasionally the
> program never terminates! I did (run 100) a fe
On Wed, Sep 16, 2009 at 6:13 AM, Krukow wrote:
> On Sep 15, 10:23 pm, Mark Volkmann wrote:
> > I think the problem is that you only ensure one of the Refs. If you
> > want to make sure that a condition between multiple Refs isn't
> > violated, you need to sure all of them. Otherwise other transa
On Sep 16, 12:32 am, Timothy Pratley wrote:
> I ran program #1 and #2 on Clojure 1.1.0-alpha-SNAPSHOT from git
> -> program #1 output skew
> -> program #2 no output
>
> What version are you using? Could be something that's been fixed
> recently.
I was running a fairly recent, but not the lates
On Sep 15, 10:23 pm, Mark Volkmann wrote:
> I think the problem is that you only ensure one of the Refs. If you
> want to make sure that a condition between multiple Refs isn't
> violated, you need to sure all of them. Otherwise other transactions
> will be free to modify the Refs that aren't e
I ran program #1 and #2 on Clojure 1.1.0-alpha-SNAPSHOT from git
-> program #1 output skew
-> program #2 no output
What version are you using? Could be something that's been fixed
recently.
On Sep 16, 6:14 am, Krukow wrote:
> After a discussion in dcug about the write-skew anomaly, I wanted t
On Tue, Sep 15, 2009 at 3:23 PM, Mark Volkmann
wrote:
> I think the problem is that you only ensure one of the Refs. If you
> want to make sure that a condition between multiple Refs isn't
> violated, you need to sure
I meant "ensure" instead of "sure".
> all of them. Otherwise other transactio
I think the problem is that you only ensure one of the Refs. If you
want to make sure that a condition between multiple Refs isn't
violated, you need to sure all of them. Otherwise other transactions
will be free to modify the Refs that aren't ensured.
On Tue, Sep 15, 2009 at 3:14 PM, Krukow wro
39 matches
Mail list logo
