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
