Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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.

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


pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group