On Tue, Jun 30, 2009 at 7:50 AM, Krukow<karl.kru...@gmail.com> wrote:
>
> On Jun 29, 7:51 pm, B Smith-Mannschott <bsmith.o...@gmail.com> wrote:
> [snip...]
>> much on my netbook. The problem seems to be that with only a single
>> (hyperthreaded) core the render agent is almost constantly interrupted
>> by some pesky ant while attempting to snapshot the world, forcing the
>> render agent to automatically retry. And so, the ants run merrily
>> around the world, only I can't see it.
>
> If my understanding of the STM is correct (and it may very well not
> be) the render function should not retry. The render function reads
> all the refs that define ant positions, but does not modify any ref.
> So I suspect that the missing renders are caused by a thread
> starvation rather than retries.
>
> But I'd like to hear if Rich agrees ;-)
>
MVCC history in Clojure's STM is dynamic, created by need. There is no
read tracking, and more important for this case, no transaction
tracking. So, if a read transaction is unable to satisfy its snapshot
view from history, it will flag the offending ref with a fault and
retry. When a writer sees a ref with a read fault it will grow history
for that ref. In this way only as much history is created as is needed
to satisfy the dynamic contention patterns, and
tracking/synchronization is minimized.
The problem for scanning readers like render is that the ref that
caused the fault this pass is unlikely to be the ref that causes the
fault next time, and it will take a while to accumulate even one step
of history for each scanned ref using the fault system.
This has caused me to implement (in git master) some long-planned
controls on ref history. You can now supply :min-history and
:max-history args to ref. The defaults are 0 and 10 respectively. By
setting min-history to some positive value, history will be
accumulated even in the absence of faults, providing a window, if you
will, for scanning readers like render.
You can see this history acquisition by periodically running:
(map ref-history-count (world 20))
while the ants demo is going.
So, now you can preemptively maintain history in the ants demo by
modifying the world init with some min-history (the value 2 below is
your 'knob' for accommodating the duration of the render sweep)
(def world ... (ref (struct cell 0 0) :min-history 2) ...)
Please let me know how that works for you, and, everyone else, please
let me know if max-history default of 10 causes you any trouble
("Transaction failed after reaching retry limit").
There will eventually be more knobs coming, to control
transaction-level retry counts and timeouts.
Rich
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
