Sunday, December 02, 2007

Reducing Lock Contention

Here is a good blog posting on 10 Ways to Reduce Lock Contention. Even though our .NET-based client-side framework behaves well, I should take these hints and examine our framework with a fine-tooth comb.

I am also following all of the recent developments in Parallel Programming coming out of Microsoft. I wonder how much Joe Duffy's team interacted with the Accelerator guys from Microsoft Labs. I am also very interested to see if our Derivatives Analytics team, which is very strong in .NET, can leverage this new technology instead of/in additon to some of the proprietary technology offered by hardware acceleration vendors.

By the way ... I just started using Google reader. This blog is one of the blogs that Google Reader automatically recommended.

©2007 Marc Adler - All Rights Reserved


Anonymous said...

A good post. We naturally worry a lot about locking in the Coral8 Engine. There are two things that kill performance like nothing else: excessive locking and excessive memory copying.

The two are related: if one does not want to copy messages, then one needs to provide shared access to these messages. This is exactly what we do: no matter how many windows contain a message, a message is never copied unless it's modified. How do we make sure you don't suffer from too much locking in this case?

Unfortunately, this is where we come to the boundary of what I can say in a public blog. We do a huge number of optimizations that deal with locking and memory access, but they all fall under our trade secrets. Hopefully some day I can say more about this in my blog

BTW, I moved to Google Reader a few days ago myself. Great minds think alike. So far it's looking pretty good.

Mark Tsimelzon
President & CTO, Coral8

Jon said...

I also enjoyed the post on reducing lock contention.

I'm also quite curious about what the future will bring in parallel computation. Will low-level primitives such as locks be replaced by higher-level concepts? That's been the dream of researchers since at least the 1970s, when features like monitors and channels, and models such as dataflow and actors, were invented. I'm partial to dataflow (the foundation of many CEP systems), as well as Concurrent ML and the join calculus (now implemented in JoCAML). All have the goal of making concurrency easier to use, where programs have fewer bugs (like high-level languages do over assembly). And good implementations of these systems probably use most, if not all, of the tricks cited.