On Tue, Mar 17, 2009 at 3:21 PM, Rich Hickey <[email protected]> wrote: > > On Mar 17, 3:21 pm, Mark Volkmann <[email protected]> wrote: >> On Tue, Mar 17, 2009 at 1:41 PM, Rich Hickey <[email protected]> wrote: >> >> > On Mar 17, 2:32 pm, Mark Volkmann <[email protected]> wrote: >> >> On Tue, Mar 17, 2009 at 8:08 AM, Jeffrey Straszheim >> >> >> <[email protected]> wrote: >> >> > The code isn't too hard to follow, 'cept the barging stuff gets a bit >> >> > tricky. A nice 10,000 foot overview would be nice, however. >> >> >> > On Tue, Mar 17, 2009 at 8:04 AM, Mark Volkmann >> >> > <[email protected]> >> >> > wrote: >> >> >> >> Is there a summary somewhere of the steps Clojure STM takes to avoid >> >> >> deadlocks? I'm just trying to understand the basics of what, if >> >> >> anything, it does to avoid them. >> >> >> I just ran across this quote from Rich Hickey near the bottom >> >> ofhttp://mail.google.com/mail/?ui=2&zx=gb3mbfrah3gv&shva=1#inbox/120148... >> >> >> “Clojure's STM and agent mechanisms are deadlock-free. They are not >> >> message-passing systems with blocking selective receive. The STM uses >> >> locks internally, but does lock-conflict detection and resolution >> >> automatically.” >> >> >> I take this to mean that it is not possible for STM transactions in >> >> Clojure to deadlock. I'm still interested in learning the basics of >> >> how it does lock-conflict detection and resolution. I haven't found a >> >> description of it anywhere. I guess I'll have to read through the >> >> code. >> >> > I really don't know why you would expect to do something other than >> > that. Explaining precisely and accurately how an STM works is not >> > something for a few paragraphs of prose. It's only about 600 lines of >> > code. >> >> > I don't want to promise anything about how the implementation works, >> > since I'd like to be free to change it. If you want to understand how >> > it currently works, the code is there. >> >> You certainly don't owe anyone a written summary of how any parts of >> Clojure work. However, surely you would agree that if such summaries >> existed, it would be easier for people interested in Clojure to get a >> general understanding much faster than reading the code. As an >> example, when people want to know how threads and locks work in Java, >> they don't usually look at the source code. There are plenty of >> tutorials on the web and books that explain it. >> >> In my case I'm having a semi-debate with someone about why coding for >> concurrency is easier in Clojure than in Java. The person I'm >> discussing this with thinks that Clojure is oversimplifying >> concurrency issues. He feels it is necessary to have a detailed >> understanding of an entire application in order to avoid deadlocks. I >> was looking for something that might convince him that it isn't true >> and that deadlocks cannot occur in Clojure. I don't think you can >> expect someone like him that is barely interested in Clojure to look >> through the source. On the other hand, if there was a page on the >> Clojure website that explained at a high level how Clojure avoids >> deadlocks, I think he would read that. >> >> I do understand though how not documenting certain things leaves you >> free to change the implementation later. > > I think you should read through some of the papers listed here: > > http://en.wikipedia.org/wiki/Software_transactional_memory > > to get a feel for what a description of an STM looks like. Clojure's > STM is not exactly like any of those, but you'll see none of those > descriptions are elevator pitches. > > also: > > http://en.wikipedia.org/wiki/Multiversion_concurrency_control > http://en.wikipedia.org/wiki/Snapshot_isolation > > for some of the other issues.
Thanks Rich! I've actually finished reading the Wikipedia entry for STM this morning and it helped me a lot. I haven't looked at the other two yet though, so I'll do that. > The bottom line is that STM implementations are complex and won't have > simple descriptions. > > If the person you are arguing with can't understand how concurrency > could be made automatic and deadlock free, have him imagine an STM > where each ref had a unique locking number and a revision, no locks > were taken until commit, and then the locks were taken in locking > number order, revisions compared to those used by the transaction, > abort if changed since used, else increment revisions and commit. > Deadlock-free and automatic. It ends up that no STM works exactly this > way, but it is an example of how the deadlock-free correctness benefit > could be delivered simply. Thanks! That helps. -- 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
