Kevin Lewis wrote:
> Jim, We would really like to see your response to this.
> -------- Original Message --------
> From: Christopher Powers <Christopher.Powers@stripped>
> 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.
President, NimbusDB, Inc.