Subject: Re: PostgreSQL
To: Garrett D'Amore <garrett_damore@tadpole.com>
From: Thor Lancelot Simon <tls@rek.tjls.com>
List: tech-perform
Date: 02/03/2006 11:41:52
On Fri, Feb 03, 2006 at 07:49:01AM -0800, Garrett D'Amore wrote:
> 
> The problem with userland code is that there are a bunch of people that
> just don't really understand concurrent programming, or good design, and
> many of those people are hacking away at userland programs.

And using threads where separate processes would clearly suffice (I've seen
few, if any, cases in which separate processes with carefully controlled
shared memory actually perform worse than multiple threads in a single
process context) enables those people to expose themselves to a whole new
world of multiprogramming bugs.

I understand that multiple threads executing in the same address space is
the current vogue among people who write programming books with glossy
covers, and perhaps in undergraduate programming sequences that begin
with Java (where the thread is the natural abstraction provided by the
language and VM) and progress to C++ (but where the instructors teaching
C++ don't really know enough about any particular operating system to
teach things like its process model).  But, really, so what?  Pascal
was in fashion for a while, too. ;-)

The Unix process model -- with the obvious, sensible extension offered
by mmap that allows processes to share _selected_ regions of memory --
allows application programmers to write concurrent applications in
which one thread of control is protected from the misbehavior of another,
while making synchronization between threads only slightly more difficult
(arguably: no more difficult, with slightly less performance; or slightly
more difficult, with equivalent performance) than in the threaded case.

Given how many programmers still manage to screw it up in the process
model I am very, very skeptical that most programmers can get it right
in the thread model.  Look how much fundamentally broken threaded code
the diagnostic assertions in our libpthread find -- and look what the
usual response of the authors of that code is when people tell them
about it: "NetBSD's libpthread is broken".  That doesn't inspire a lot
of confidence, either.

Thor