Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Clojure
Home
+ new post
About this group
Join this group
Message from discussion STM criticism from Azul Systems
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
cliffc  
View profile  
 More options May 23 2008, 2:13 pm
From: cliffc <cli...@acm.org>
Date: Fri, 23 May 2008 11:13:05 -0700 (PDT)
Local: Fri, May 23 2008 2:13 pm
Subject: Re: STM criticism from Azul Systems
Print | View thread | Show original | Report this message | Find messages by this author
You got it - under load, performance is unpredictable.

With locks, you can see which locks are loaded, generally figure out
why, and plan a strategy (stripe the lock, shorter hold time, switch
to the j.u.concurrent datastructures, etc).

Not so (at least not yet) with STM.  I've talked to a few people
who've tried STM out in a larger scale than the usual academic papers
- and the results are downright disappointing.  Unless you become an
expert in the STM runtime you're using (where "expert" means "not just
grok it, but can build & tweak it") anytime performance is not good
enough - you get stuck.  This is an open research problem at best,
with no clear indication that the problem can be solved at all.

Cliff

On May 23, 11:07 am, "Raoul Duke" <rao...@gmail.com> wrote:

> > Are explicit locking designs free from such anomalies? I wouldn't think
> > so.

> paraphrase: the behaviour under load gets weird and tricky.

> well, in some ways maybe that doesn't happen with locks: the question
> of (depending on which STM system we're looking at) figuring out what
> caused all the rollbacks vs. with locks, you can at least generally
> quickly see that a given lock has 90% of all threads waiting on it
> kind of thing. whereas you don't know what variable in the venn
> diagram of overlapping transactions caused the retry?

> tho i believe Rich previously said that Clojure would actually have a
> way of finding that out!http://groups.google.com/group/clojure/browse_thread/thread/2f73b80fd...


 
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.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2012 Google