Concurrency, was Re: Doh! Stupid Programming Mistakes <humor>

Levi Pearson levi at cold.org
Thu Oct 19 13:34:11 MDT 2006


On Oct 19, 2006, at 1:00 PM, Topher Fischer wrote:

> Dr. Mercer's Computer Architecture (CS345) class gave me my only
> experience with a practical use of forking.  We wrote a small UNIX
> shell, and when the user typed in a command, the program would fork.
> This creates a new process with its own memory space, file descriptor
> table, signal handlers, etc.  The child process would then exec (man 3
> exec) the user's command, which takes over the process that was  
> created
> by the fork command.  If concurrency is the only goal, then threads  
> will
> usually take care of the problem.  However, if you need a  
> completely new
> process with its own resources, then fork you.  I mean, then you fork.
>

If concurrency is the only goal, then it would be best to analyze  
your needs before choosing threads over processes.  In Linux, at  
least, both have similar overhead.  Processes simply have a flag that  
says that the heap should be copy-on-write instead of shared, IIRC.   
The big advantage of a process over a thread is that you get to take  
advantage of the built-in memory protection that Linux gives you.   
By /not/ sharing memory by default, you knock out the  
nondeterministic interleaving of execution threads that you get with  
shared memory, which makes understanding your program's behavior much  
simpler.

If passing messages or setting up explicit shared memory turns out to  
be far more awkward, and your problem doesn't involve too many hairy  
locks and such, threads might be a good solution.  But in Linux, you  
shouldn't reach for them unless you've clearly demonstrated to  
yourself that the benefits outweigh the costs.

		--Levi



More information about the PLUG mailing list