From: Jim Starkey Date: December 8 2008 11:08pm Subject: Re: [Fwd: Real-World Concurrency] List-Archive: http://lists.mysql.com/falcon/279 Message-Id: <493DA8EB.3000004@nimbusdb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Kevin Lewis wrote: > Jim, We would really like to see your response to this. > > -------- Original Message -------- > From: Christopher Powers > > 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