On Sep 5, 10:30 am, Krukow <karl.kru...@gmail.com> wrote:
> I am digging somewhat into Clojure internals for a talk I'm doing. Now
> I've reached the LockingTransaction class, and have a few questions, I
> hope someone can answer.
>
> In some of the Clojure presentations it says that "Readers never
> impede writers/readers, writers
> never impede readers". What does the word "impede" mean in this
> context?
>
> At first, before reading the code, I thought it meant that, e.g., a
> read-only transaction, R, can never be retried, even if a concurrent
> writing transaction, W, changes a ref that is read later by the R. But
> that is not the case; see e.g.,
>
> http://groups.google.com/group/clojure/browse_frm/thread/e9b56115929f...
>
> I see that LockingTransaction.doGet may mark a fault and retry.
>
> So what exactly *is* meant by "never impedes"?
Given sufficient history, readers will not be retried due to the
activity of writers. It is true that while history is being
dynamically acquired there may be retries. Unless you have some
pathological transaction relationships, that history acquisition will
occur in a small amount of time, and thus is being ignored as would a
constant factor. Perhaps 'never' is too strong a term, but history
acquisition is somewhat of an implementation detail. If that build-up
phase is an actual problem, you now have :min-history to mitigate it.
>
> 2) All the refs in a program are controlled by the same STM system.
> Suppose you have two disjoint sets of refs, A and B, in a program,
> and suppose that all transactions only touches either A or B. Would
> there be any value in having two STM instances controlling A and B,
> e.g., by labling each ref with 'A' or 'B.' It would mean that
> transactions are sourcing readPoints from distict sources and thus
> less synchronization (although the overhead for AtomicLong is pretty
> low, this might matter for many-core situations).
>
There is potential for a 'separate worlds' design, but the devil is in
the details of allocation of refs to worlds. While the single shared
CAS is a theoretical bottleneck, I'd have to see it become an actual
bottleneck before introducing that complexity.
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
-~----------~----~----~----~------~----~------~--~---
