cbbrowne@cbbrowne.com wrote:
> > > That's an awful lot of very bright programmers and some serious $$
> > > voting that threads are worth it.
> >
> > For THAT application. for what a web server does, threads can be very
> > useful, even useful enough to put up with the problems created by running
> > threads on multiple threading libs on different OSes.
> >
> > Let me ask you, if Zeus scrams and crashes out, and it's installed
> > properly so it just comes right back up, how much data can you lose?
> >
> > If Postgresql scrams and crashes out, how much data can you lost?
>
> There's another possibility, namely that the "voting" may not have
> anything to do with threading being "best." Instead, it may be a
> road to allow the largest software houses, that can afford to have
> enough programmers that can "do threading," to crush smaller
> competitors. After all, threading offers daunting new opportunities
> for deadlocks, data overruns, and crashes; if only those with the
> most, best thread programmers can compete, that discourages others
> from even /trying/ to compete.
Yes, but any smart small software shop will realize that threading is
more about buzzword compliance than anything else. In the real world
where things must get done, threading is just another tool to use when
it's appropriate. And the only time it's appropriate is when the
amount of time it takes to create, manage, and tear down a process is
a very large fraction of the total amount of time it takes to do the
work.
If we're talking about databases, it's going to be very rare that
threads will *really* buy you any significant performance advantage
over concurrent processes + shared memory.
Buzzword compliance is nice but it doesn't get things done. At the
end of the day, all that matters is whether or not the tool you chose
does the job you need it to do for as little money as possible. I
hope in this lean economy that people are starting to realize this.
--
Kevin Brown kevin@sysexperts.com
