Loan, thank you! kl. 21:03:59 UTC+1 søndag 26. oktober 2014 skrev Leon Grapenthin følgende: > > > > 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. >
So, this is basically as with atomics, no signalling? Is this because as such signalling is not needed, the basic algorithms that this is used on don't need such signalling? And if it's needed, then semaphors etc. may be built on top of these? A critical region has no signalling either, and it's ok in the context I, as an embedded programmer would most often see it: communication with interrupts. But of course, this involves some kind of polling to pick up something that's delivered from an interrupt. > > >> >> 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. > Good to have this confirmed, it helps my understanding; I haven't seen that sentence before. > >> [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. > Very interesting! > > >> >> 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.
