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.
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. /mike. 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 > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
