 |
From: Phil Jordan <li...@philjordan.eu>
Date: Sun, 25 May 2008 18:31:31 +0200
Local: Sun, May 25 2008 12:31 pm
Subject: Re: STM criticism from Azul Systems
I'm new to STM, I've stumbled into it after doing some
explicit/low-level lock-free programming and systems that are synchronised classically with mutex/semaphore-based locking. I especially don't know what goes on under the hood in Clojure's STM implementation, or how powerful the JVM is in terms of memory guarantees. I'm chipping in out of interest and to improve my understanding, cliffc wrote: From personal experience, this is far from the truth in complex > On May 24, 10:51 am, Rich Hickey <richhic...@gmail.com> wrote: >> As we add locks, performance of both approaches improves, but a new >> source of errors comes into play for the manual approach - lock >> acquisition order and the resultant deadlock risk. At this point STM >> becomes dramatically less complex than manual locking. > Not interesting *in practice*. Because in practice, deadlocks are systems. Deadlocks happening only on "in the wild" systems, appearing in the form of heisenbugs, etc. Not fun at all. There's too much in the way of implicit contracts going on, which blows up in your face if you're trying to extend undocumented software that was written by someone who left the company before you arrived. (and we all know the "well then document it" approach just doesn't happen in practice) Maybe it's just the implementations I've used (pthreads, Win32, OpenMP) > You get a crash dump, crawl the stacks, discover the lock cycle & You need a reasonable amount of infrastructure in place for that, plus > reorganize. > Sure the situation could be better, but deadlocks are a 'crash once' > kind of bug. you're relying on absence of evidence rather than proof that it can't deadlock. > Dev's don't like 'em, but they don't lose sleep over them either. The people who lose sleep over software quality are probably the kind who try to avoid complex locking schemes like the plague in the first place. :) > Ok, the long sought after counter example.: STM's do not compose w/ My understanding is that this is exactly the kind of situation where STM > correctness. > Bad Java syntax follows, because I don't 'speak' Clojure. I'm using > the classic example. > class Account { > transfer( Account a1, Account a2, long m ) { > While 'add' alone is STM'd & safe, the two calls to 'add' that need to excels: you wrap the two add calls in a transaction rather than making them individually atomic. The way Clojure handles this (I've been spending 99.9% of my time in Clojure on non-threaded things, so I could easily have missed something) is that your _money would be a ref, and any attempt at modifying it will fail unless you're in a transaction. Wrapping the 'add' around the transaction would be the anti-pattern here, you want to make the 'transfer' a transaction. > Less trivial examples quickly spiral out of control. Sure I know Okay, you kind of lost me with what you're trying to say here. > Ref's A, B & C are all Ref's and thus only updated in 'dosync' blocks > - but can I split any collection of Ref updates into more than one > atomic region? The ad-absurdum answer is to wrap a dosync around > *all* Ref's - which means the whole program, and that means a single- > threaded program. Imagine the program unrolled in front of you, as an > endless sequence of actions (all control flow flattened out)... > interspersed with other actions are updates to Ref's. Now: dissect > this list into groups with 'atomic' or 'lock' as you see fit, > preserving the program meaning as another unrolled thread of execution > is interspersed. How do you decide where it's OK to split the stream > and where it's not OK? > Why, in the Grand Scheme of things is: "... { read _money ... write I get the impression you're mixing up atomic operations on the low level ~phil You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
| |||||||||||||