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: http://lists.mysql.com/falcon> To unsubscribe: http://lists.mysql.com/falcon?unsub=1>
>
--
Mark Callaghan
mdcallag@stripped

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.