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.

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.

Rich

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to