On Sunday, October 26, 2014 11:37:43 AM UTC+1, Øyvind Teig wrote: > > I have been reading myself up on Clojure concurrency, starting at [1]. In > [2] I read that > > The Clojure STM uses multiversion concurrency control with adaptive >> history queues for snapshot isolation, and provides a distinct commute >> operation > > > but it still needs some explanation to me. Software transactional memory > (STM) is described ok. > > But the "adaptive history queues" looks like implementation. In ADA, tasks > on rendezvous queue up (so the Ravenscar high security profile prohibits > them because they are non-deterministic). In Go goroutines on selective > choice's select are queued (also nondeterministic). In occam the there is > no such queue on the ALT. How is the Clojure queue, and what does it > contain? > > I see that exchanging data between Clojure concurrent functions (threads?) > described. But I haven't discovered how a "thread" that succeeds in > writing, followed by a successful write immediately after by another thread > - is "signalled" to the first thread? Is there any *wait* type of > mechanism? > There is no signalling. The "write" in the first thread always succeeds within the transaction but the "real world" is not affected until the transaction succeeds as a whole. If during the transaction another transaction succeeded, it is retried as a whole, potentially with the new values written by the other transaction, until it has also succeeded.
> > If a write fails and there is a retry, what's the limit of retries, is > there a yield in between, and in case, how is this entry queued? > There is no limit. (Unfortunately I don't know about the implementation details and hopefully somebody else can enlighten you on that.) > > Is it correct to say that *never to block means never to be 100% sure > that a transaction succeeds at first attempt*? > Yes. > > [3] states on commute that "Thus fun should be commutative, or, failing > that, you must accept last-one-in-wins behavior. commute allows for more > concurrency than ref-set.". What's the metric of concurrency? No, little, > some, more, much, max? > How much happens at the same time in contrast to being queued up. Remember that only successful transactions affect the outside world. E. g.: Of two successful transactions, one had to be restarted because of the other completed during its first try => The two successful transactions didn't happen in parallel. Using commute reduces the potential of a retry and thus allow more successful transactions in parallel => more concurrency. > > I would have more questions, but they will come. > > I plan to blog about these matters at [4]. It's a do-for-fun only blog, > with no money or ads involved. I try to read myself up via atomic to > several other concurrency models than CSP, which is flowing in my veins the > last 25 years. > > Øyvind Teig, Trondheim, Norway > > [1] - http://clojure.org/concurrent_programming > [2] - http://clojure.org/Refs > [3] - > http://clojure.github.io/clojure/clojure.core-api.html#clojure.core/commute > [4] - http://www.teigfam.net/oyvind/home/technology/ > -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
