See also on this
Threads Primer, Lewis & Berg ISBN 0-13-443698-9 
Programming With Threads, Kleiman, Shah & Smaalders ISBN 0-13--172389-8

A good place to start on this area is

www.sun.com/sunsoft/Products/Developer-products/sig/threads/resources.html

Dominic Kay
Unix Sysadmin
Dell 


______________________________ Reply Separator _________________________________
Subject: Re: threads versus processes
Author:  current-users-owner-Dominic_Kay=dell.com@NetBSD.ORG at dell_unix
Date:    20/01/97 17:10


On Mon, 20 Jan 1997 13:51:36 -0800, "Erik E. Fair" (Time Keeper) 
<fair@clock.org> wrote:
> At 12:26 -0800 1/20/97, Christian Kuhtz wrote: 
>
> >For efficient multiprocessing, threading is a requirement, not an option. 
>
> Can you cite a reference study for this assertion?
     
Does personal experience over the past years count, too? ;-)
     
You can deduce the above assertion by looking at how threads work.
     
The time neccessary to create a process as opposed to a thread is 
considerable, as well as memory being replicated for the new process.
     
Once a process is alive, the cost of interprocess communication and shared 
memory/data synchronization comes into play.  Threads share everything by 
default, except their program counter and a small number of other thread 
relevant pieces of information.  Processes do not share everything by default,
     
although their memory images are (nearly) identical.
     
Also, the scheduling effort for a new process much higher than "lightweight" 
thread creation.
     
Processes can only synchronize by executing system calls, which are 
expensive, whereas threads synchronize by monitoring variables.  Kernel space 
is not entered and the operation happens entirely in userspace.
     
Based on those performance advantages, and personally I find threads much 
easier to handle than process, YMMV, the above assertion can be made.
     
Let's see here, what have we got as far as pubs are concerned, the most 
recent and easiest to read is probably the following:
     
Pthreads Programming; Nichols, Buttlar and Proulx Farrel;  O'Reilly & Assoc., 19
     
96
     
It contains many, many examples of threading and how to do it, and I'm sure 
if you read all the comments about why things are done a certain way, or how
things can be done in the first place, you will understand the above much more
     
thoroughly.  It will become clear that the above is the only logical 
deduction.
     
Virtually any kind of Mach C-Threads, Pthreads implementation documentation 
will have pointers to it.  I need to go dig in my library for more information
     
about specific *studies* talking about this.  It is an otherwise commonly 
accepted fact, as in 1+1=2 ;-).  Any who disagrees with that?
     
It might also be in the POSIX standards, and I'm going to attempt to find them.
     
;-)
     
The drawback about threading is that you need to know fairly well what you 
are doing, since you don't have a quite as thick cussion by default... *you* 
are responsible for making sure that you do have a cussion (read: make sure 
your code is sane) and avoid programming errors.  But then again, that's 
always the case anywhere.
     
Regards,
Chris