3 Feb 2006 17:41
Re: PostgreSQL
Thor Lancelot Simon <tls <at> rek.tjls.com>
2006-02-03 16:41:52 GMT
2006-02-03 16:41:52 GMT
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
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
RSS Feed