Re: Spinlock performance improvement proposal - Mailing list pgsql-hackers

From Doug McNaught
Subject Re: Spinlock performance improvement proposal
Date
Msg-id m3y9n11sr3.fsf@belphigor.mcnaught.org
Whole thread Raw
In response to Re: Spinlock performance improvement proposal  ("D. Hageman" <dhageman@dracken.com>)
Responses Re: Spinlock performance improvement proposal  ("D. Hageman" <dhageman@dracken.com>)
Re: Spinlock performance improvement proposal  (Chamanya <chamanya@yahoo.com>)
List pgsql-hackers
"D. Hageman" <dhageman@dracken.com> writes:

> Save for the fact that the kernel can switch between threads faster then 
> it can switch processes considering threads share the same address space, 
> stack, code, etc.  If need be sharing the data between threads is much 
> easier then sharing between processes. 

This depends on your system.  Solaris has a huge difference between
thread and process context switch times, whereas Linux has very little 
difference (and in fact a Linux process context switch is about as
fast as a Solaris thread switch on the same hardware--Solaris is just
a pig when it comes to process context switching). 

> I can't comment on the "isolate data" line.  I am still trying to figure 
> that one out.

I think his point is one of clarity and maintainability.  When a
task's data is explicitly shared (via shared memory of some sort) it's
fairly clear when you're accessing shared data and need to worry about
locking.  Whereas when all data is shared by default (as with threads)
it's very easy to miss places where threads can step on each other.

-Doug
-- 
In a world of steel-eyed death, and men who are fighting to be warm,
Come in, she said, I'll give you shelter from the storm.    -Dylan


pgsql-hackers by date:

Previous
From: Martín Marqués
Date:
Subject: pg_dump bug
Next
From: "D. Hageman"
Date:
Subject: Re: Spinlock performance improvement proposal