On Tue, Jun 30, 2009 at 18:01, Rich Hickey<richhic...@gmail.com> wrote:
>
> 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").Sorry it took me so long to try this out... I've tried this with a build of a1397390d8b3b63f2039359520629d87b152d717 (July 4), I tried :min-history values of 2 and 9, which didn't help, meaning the window stayed blank because the rendering agent does not run to completion. I was able to get something to display by dialing :min-history up to 100. It draws less than one frame per second, but it does draw. (Perhaps it's too much to expect for a single core to juggle some 50 threads.) I'm going to play around with it some more and see what I find. // Ben --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
