Re: Spinlock performance improvement proposal

From: Doug McNaught <doug(at)wireboard(dot)com>
To: "D(dot) Hageman" <dhageman(at)dracken(dot)com>
Cc: mlw <markw(at)mohawksoft(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Spinlock performance improvement proposal
Date: 2001-09-26 22:39:44
Message-ID: m3y9n11sr3.fsf@belphigor.mcnaught.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"D. Hageman" <dhageman(at)dracken(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Martín Marqués 2001-09-26 22:43:44 pg_dump bug
Previous Message Ian Lance Taylor 2001-09-26 22:04:41 Re: Spinlock performance improvement proposal