List:Falcon Storage Engine« Previous MessageNext Message »
From:Jim Starkey Date:December 8 2008 11:08pm
Subject:Re: [Fwd: Real-World Concurrency]
View as plain text  
Kevin Lewis wrote:
> Jim, We would really like to see your response to this.
> -------- Original Message --------
> From: Christopher Powers <Christopher.Powers@stripped>
> Greetings,
> Attached is an excellent article on concurrency by Brian Cantrill and
> Jeff Bonwick at Sun. Reprinted from the November 8 issue of
> "Communications of the ACM".
Much truth and wisdom there.  My favorite quote:

    But what if you are the one developing the operating system or
    database or some other body of code that must be explicitly
    parallelized?  If you count yourself among the relatively few who
    need to write such code, you presumably do not need to be warned
    that writing multithreaded code is difficult.

Anyone disagree with this?

The hot path / cold path analysis is excellent.  We do that implicitly, 
but have never had a name for it.

I also applaud the idea that design must be data driven.  That said, 
there must also be intelligent analysis of that data.  There are many 
ways to work around a hot spot.  Moving work outside of the lock is 
easy.  Non-blocking, concurrent data structures are an absolute last 
resort (Olav, do you agree?).  There are many tools; pick the most 
appropriate for a given problem is critical.  So, might I add, is 
introducing complex solutions to non-problems.  We do need better data 
on contention in SyncObjects with encumbering them with overhead that 
masks the actual working (i.e., keeping an accurate count doubles the 
cost of taking a lock).

I do disagree with his analysis of read/write vs. mutex.  Yes, a read 
lock costs just as much as mutex, but that isn't the point.  The point 
is that read locks don't block other readers, and when read locks 
predominate, this is a huge win.  Do noote, however, that the SyncObject 
is designed to handle the recursion problem that they describe.  That, 
in fact, was the other prime motivator for SyncObject.

I do wish that a way could be found to move DTrace in Linux.  The GPL 
license issue is infuriating: Linux can take DTrace under GPL because 
they would have to publish any changes to DTrace under the original 
DTrace license, and GPL doesn't permit giving back.   Grrrr.

Another thing worth looking at is explicit per-thread structures like 
MemThreadCache.  No locking is very cheap locking.

I think you guys are missing something important by not exploring cycle 
locking.  It's a very powerful tool.  I'm using it in Nimbus with great 
success.   The water's warm, come on in.

Jim Starkey
President, NimbusDB, Inc.
978 526-1376

Re: [Fwd: Real-World Concurrency]Jim Starkey9 Dec
  • Re: [Fwd: Real-World Concurrency]MARK CALLAGHAN9 Dec
    • Re: [Fwd: Real-World Concurrency]Jim Starkey9 Dec
    • Re: [Fwd: Real-World Concurrency]Jim Starkey9 Dec