On Fri, 3 Feb 2006, Garrett D'Amore wrote:

> The problems with MT programs really have a lot more to do with shared
> state, I think.  Folks who don't understand locking considerations (how
> to avoid deadlock, priority inversion, etc.) struggle with it.

It's also the lack of good tools, I think. At this point, our
systems for decomposing and recomposing single-threaded code (i.e.,
modularization). For for concurrent code, we don't have such things;
every time you take two separate concurrent operations and put them
together, you have to deal with all of the concurrency considerations
again.

This paper takes a stab at helping with this:

     http://research.microsoft.com/~simonpj/papers/stm/index.htm

> 5) ultimately, threading for them does very little for DB performance --
> most of the benefit is in connection setup, and the belief is that this
> should not be considered in the hot-path of a DB application --
> connection caching and pooling is seen as a better way to optimize this

I'd say that that's definitely the biggie. The one relatively common
case where processes rather than threads are a problem is when you're
holding open a lot of connections--thousands or tens of thousands. But
to fix that, you don't need to thread the entire app; you can just
have a front end that maintains connections and their state, and when
a connection needs service, it hands off the actual work to one of the
back ends.

> All that said, there is some thought that limited use of MT could
> improve e.g. parallel sorts, etc.

I wonder about that. Sorts, in particular, once they get large will
almost inevitably be spooled out to disk, which may well be the biggest
performance issue with them.

cjs
-- 
Curt Sampson            <cjs@cynic.net>             +81 90 7737 2974
   The power of accurate observation is commonly called cynicism
   by those who have not got it.    --George Bernard Shaw