On Sat, Sep 5, 2009 at 9: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.
I have lots of detail on this in my article at http://ociweb.com/mark/stm/article.html. > 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? I'd say it means "block" as in wait until the other finishes. > 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/e9b56115929fd199/f3ae6306214a0b0d A transaction A that only reads Refs won't have to wait for a transaction B that writes the same Refs to complete in order for it to do its work. It is possible though that transaction A will have to retry. This happens if the history chain for a Ref that is being read within transaction A doesn't contain a value that was committed before transaction A started. And that can happen if a number of transactions committed changes to the Ref since transaction A started. How many commits would their have to be? It depends on the current length of the history chain for the Ref being read. See my article for more detail on how the history chain grows. > I see that LockingTransaction.doGet may mark a fault and retry. Right. A fault is the situation I described above when a transaction tries to read a Ref, but its history chain doesn't contain a value that was committed before the current transaction try began. > So what exactly *is* meant by "never impedes"? Doesn't block. > 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). I can't see how this would help. There is very little synchronization now. The current STM seems pretty optimized. For example, each Ref keeps track of its own history. The transactions keep track of changes they have made to Refs that haven't been committed yet. Search for "overhead" in my article to see a detailed description of the overhead introduced by Clojure STM. Even though there are a lot of steps involved, I think the overhead is pretty minimal. Also, see the article description of the lock field in the Ref class for a description of all the ways that locks are used by Clojure STM (http://java.ociweb.com/mark/stm/article.html#lock-field). Almost all the locks are acquired and only held for a brief period of time, not for the duration of a transaction. -- R. Mark Volkmann Object Computing, Inc. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
