Re: Using Threads?

On Mon, Dec 04, 2000 at 03:17:00PM -0800, Adam Haberlach wrote:
>     Typically (on a well-written OS, at least), the spawning of a thread
> is much cheaper then the creation of a new process (via fork()).

Unless I'm mistaken, the back-end is only forked when starting a new
connection, in which case the latency of doing the initial TCP tri-state
and start-up queries is much larger than any process creation cost.  On
Linux 2.2.16 on a 500MHz PIII, I can do the fork/exit/wait sequence in
about 164us.  On the same server, I can make/break a PostgreSQL
connection in about 19,000us (with 0% CPU idle, about 30% CPU system).
Even if we can manage to get a thread for free, and assume that the fork
from postmaster takes more than 164us, it won't make a big difference
once the other latencies are worked out.

> Also, since everything in a group of threads (I'll call 'em a team)

Actually, you call them a process.  That is the textbook definition.

> shares the
> same address space, there can be some memory overhead savings.

Only slightly.  All of the executable and libraries should already be
shared, as will all non-modified data.  If the data is modified by the
threads, you'll need seperate copies for each thread anyways, so the net
difference is small.

I'm not denying there would be a difference.  Compared to seperate
processes, threads are more efficient.  Doing a context switch between
threads means there is no PTE invalidations, which makes them quicker
than between processes.  Creation would be a bit faster due to just
linking in the VM to a new thread rather than marking it all as COW.
The memory savings would come from reduced fragmentation of the modified
data (if you have 1 byte modified on each of 100 pages, the thread would
grow by a few K, compared to 400K for processes).  I'm simply arguing
that the differences don't appear to be significant compared to the
other costs involved.
--
Bruce Guenter <bruceg@em.ca>                       http://em.ca/~bruceg/