Subject: Re: threads versus processes
To: Erik E. Fair <fair@clock.org>
From: Christian Kuhtz <kuhtz@ix.netcom.com>
List: current-users
Date: 01/20/1997 17:10:49
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., 1996

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