List:Falcon Storage Engine« Previous MessageNext Message »
From:MARK CALLAGHAN Date:December 9 2008 12:07am
Subject:Re: [Fwd: Real-World Concurrency]
View as plain text  
On Mon, Dec 8, 2008 at 3:08 PM, Jim Starkey <jstarkey@stripped> wrote:
> 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 hacked --with-fast-mutexes to do this for MySQL 5.1 with
pthread_mutex_t, but only for performance debugging builds. So I don't
mind the overhead that much and if you look at the code path layered
on top of this, it doesn't add much. But your SyncObjects might not be
as heavy.

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

Double grrr.  I have spent the past week working part-time trying to
find out what a certain storage engine is not as fast as I want it to
be on a certain workload. It isn't CPU bound. It is wall clock bound,
at least I need to figure out where the wall clock time is spent.
Guess, rerun, guess, rerun, wish for OpenSolaris, rerun.

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

What is cycle locking?

> --
> Jim Starkey
> President, NimbusDB, Inc.
> 978 526-1376
> --
> Falcon Storage Engine Mailing List
> For list archives:
> To unsubscribe:

Mark Callaghan
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