On Mon, Aug 17, 2009 at 2:47 PM, Michael Reid<kid.me...@gmail.com> wrote: > > Hi, > > Ditto on the ordering example. Clojure can't infer which order your > code needs to run any more than it can figure out what your code is > supposed to do.
Okay. I was pretty sure that was the case, but just wanted to verify that there wasn't something special going on that I was missing. > On the deadlock question, it is my understanding from a prior post by > Rich that Clojure's STM acquires locks in such a way that deadlocks > cannot occur (as I recall, the locks are sorted by numeric ID an > acquired/released in that order). If a deadlock occurs in the STM, my > understanding is that would be a bug. > > So yes, the Clojure STM should guarantee that a deadlock situation > does not occur. I think it's a common misconception that STM in general just manages locks for you and basically uses them in the same way you would if you were hand-coding lock-based concurrency. I can say with certainty after studying the Clojure STM implementation for over a month that that isn't the case. Refs in Clojure STM each have a ReentrantReadWriteLock object. Any number of concurrent transactions can hold the read lock for a Ref OR a single transaction can hold the write lock for a Ref. The only time one of these locks is held for the duration of a transaction is when you call ensure on a Ref. In that case it will hold a read lock until either the Ref is modified in the transaction or until the transaction commits. There is no circumstance under which a write lock will be held for the duration of a transaction. Write locks are obtained only briefly when certain things occur during a transaction and then quickly released. They are acquired again when the transaction commits and then released when the commit completes. The way that one transaction knows that another one has modified a Ref and hasn't yet committed is that the tinfo field of the Ref is set to refer to an object that describes the transaction that modified the Ref (including the order in which it started relative to others and its current status). So locks are not sorted by a numeric ID. It is transaction starts, tries and commits that are numbered that way. It's a beautiful and complicated strategy ... but it leaves me wondering whether there is any possibility of deadlock. I don't see how it could happen. I'm just asking in case I overlooked something. > On Mon, Aug 17, 2009 at 2:12 PM, CuppoJava<patrickli_2...@hotmail.com> wrote: >> >> I don't have enough knowledge to answer the deadlock question. But I >> can offer you my opinion about your question on race conditions. >> >> In your example, the result WILL depend on which transaction is run >> first. >> However I think practically this isn't a problem, because of the >> following: >> >> As a developer, when you split your task into multiple parallel >> operations (ie. threads), you're already acknowledging that the order >> in which they run shouldn't matter. If order does matter, you probably >> wouldn't have written it using multiple threads. >> >> That's my understanding anyway. Which is why haven't run into any >> problems with race conditions (as of yet). >> -Patrick -- 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 -~----------~----~----~----~------~----~------~--~---
