* Neil Conway <neilc@samurai.com> [060201 18:49] wrote:
> On Thu, 2006-02-02 at 00:49 +0000, segv@netctl.net wrote:
> > 1. I was reading somewhere that PostgreSQL was not multithreaded. This can have
> > a significant impact if you have a busy database server. Multicore CPUs
> > designed for executing 10s and 100s of threads simultaneously are just around
> > the corner (Sun's T1 processors). So fine grained threaded applications are the
> > future.
> 
> Whether threads or processes are used to implement concurrency does not
> really affect how fine-grained the concurrency is. That is, I don't see
> how using multiple processes and fork() makes an application inherently
> less suitable to multicore servers than an application using threads.

Ok, I'm on the fence about threads, but the reason why they are a
gain over processes, on multi-core in particular is that the shared
address space means that if you switch between two threads you do
not have to invalidate tlbs or caches during the context switch.

Also, thread to thread synchronization is somewhat faster than process
to process synchronization.  Honestly, the default thread synchronization
primitives typically blow the inter-process ones out of the water,
although there are some OS's and libraries that provide relatively
fast/cheap inter process syntonization.

Also, I'm pretty sure that synchronization between threads doesn't
require locked bus cycles, only atomic ops, again another saving.

But threads aren't always the best thing out there, the code gets
a lot more complicated and crash prone and you wind up sometimes
getting screwed because third party code isn't thread safe...

-- 
- Alfred Perlstein