Concurrency, was Re: Doh! Stupid Programming Mistakes <humor>
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
> by the fork command. If concurrency is the only goal, then threads
> 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
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.
More information about the PLUG