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

Re: Reasoning behind process instead of thread based

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Thomas Hallgren <thhal(at)mailblocks(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Reasoning behind process instead of thread based
Date: 2004-10-28 09:58:18
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-general
On Thu, Oct 28, 2004 at 12:13:41AM +0200, Thomas Hallgren wrote:
> Martijn van Oosterhout wrote:
> >A lot of these advantages are due to sharing an address space, right?
> >Well, the processes in PostgreSQL share address space, just not *all*
> >of it. They communicate via this shared memory.
> >
> Whitch is a different beast altogether. The inter-process mutex handling 
> that you need to synchronize shared memory access is much more expensive 
> than the mechanisms used to synchronize threads.

Now you've piqued my curiosity. You have two threads of control (either
two processes or two threads) which shared a peice of memory. How can
the threads syncronise easier than processes, what other feature is
there? AFAIK the futexes used by Linux threads is just as applicable
and fast between two processes as two threads. All that is required is
some shared memory.

Or are you suggesting the only difference is in switching time (which
is not that significant).

Also, I admit that on some operating systems, threads are much faster
than processes, but I'm talking specifically about linux here.

Thanks in advance,
Martijn van Oosterhout   <kleptog(at)svana(dot)org>
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

In response to


pgsql-general by date

Next:From: Thomas HallgrenDate: 2004-10-28 10:15:35
Subject: Re: Reasoning behind process instead of thread based
Previous:From: JoelDate: 2004-10-28 08:00:07
Subject: Re: compatibilityissues from 7.1 to 7.4

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