On Mon, Mar 15, 2010 at 5:17 PM, Christophe Grand <christo...@cgrand.net> wrote:
> On Mon, Mar 15, 2010 at 10:41 PM, ataggart <alex.tagg...@gmail.com> wrote:
>>
>> On Mar 15, 1:43 pm, Michał Marczyk <michal.marc...@gmail.com> wrote:
>> > On 15 March 2010 21:08, Meikel Brandmeyer <m...@kotka.de> wrote:
>> >
>> > > Now I'm confused. Calling ensure on r shouldn't have an effect since
>> > > we
>> > > call alter on r anyway, no?
>> >
>> > ensure "protects the ref from modification by other transactions"
>> > (from the docs). alter does not.
>> >
>> > Reading into the Java code, ensure puts a lock on the ref, which, once
>> > in place, guarantees that the transaction doing the ensuring has an
>> > exclusive right to modify the ref until it commits / retries... or
>> > something, my Java-fu is still nothing to boast about, regrettably.
>> >
>> > At any rate, my current understanding is that, in Garth's example, the
>> > ensure gives (alter r f) all the time it needs to modify r's value
>> > while putting all other transactions which attempt to modify r on
>> > hold. alter, by itself, never interferes with background transactions;
>> > should something disappear from under its feet, it expects to be
>> > retried.
>> >
>> > Ok, back to improving my Java chops in the hope of grasping all the
>> > intricasies of Rich's code sometime... *sigh*
>> >
>> > Sincerely,
>> > Michał
>>
>> I'm inclined to say this is incorrect as I'm on my iphone so I can't
>> look at the source. The concurrency functions (e.g., ref-set, alter,
>> ensure) only lock their refs during the commit process.
>
> Michal is right: ensure effectively readlocks the ref -- ref-set (and alter
> since it is currently implemented on top of ref-set) writelocks a ref twice:
> the first time to "touch" it, the second time to commit.
>
> However I think it's trying to read too much in "Protects the ref from
> modification by other transactions" to conclude that ensure guarantees the
> ref to be locked.
>
>> The issue Garth describes is a case of live-locking, an extant failure
>> mode of the STM. Some solutions would be to break up the work from
>> just a single transaction (though sacrificing consistency), or use the
>> locking construct:
>>
>> http://richhickey.github.com/clojure/clojure.core-api.html#clojure.core/locking
>>
>
> One should also try to put most of the calculation outside of the
> transaction or to make retries cheapr (eg through partial memoization).
I make no claims about the Rightness of this suggestion, but
simply offer another example of a work-around:
(dosync (alter r identity) (alter r f))
That is, a "dummy write" via alter is also sufficient to allow
the transaction to succeed, just like 'ensure'.
--Chouser
--
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 new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
