Threads vs Processes

[John Henry]

sjdevnull at yahoo.com wrote:
> sjdevnull at yahoo.com wrote:
> > John Henry wrote:
> > > Granted.  Threaded program forces you to think and design your
> > > application much more carefully (to avoid race conditions, dead-locks,
> > > ...) but there is nothing inherently *non-robust* about threaded
> > > applications.
> >
> > Indeed.  Let's just get rid of all preemptive multitasking while we're
> > at it
>
> Also, race conditions and deadlocks are equally bad in multiprocess
> solutions as in multithreaded ones.  Any time you're doing parallel
> processing you need to consider them.
>

Only in the sense that you are far more likely to be dealing with
shared resources in a multi-threaded application.  When I start a
sub-process, I know I am doing that to *avoid* resource sharing.  So,
the chance of a dead-lock is less - only because I would do it far
less.

> I'd actually submit that initially writing multiprocess programs
> requires more design and forethought, since you need to determine
> exactly what you want to share instead of just saying "what the heck,
> everything's shared!"  The payoff in terms of getting _correct_
> behavior more easily, having much easier maintenance down the line, and
> being more robust in the face of program failures (or unforseen
> environment issues) is usually well worth it, though there are
> certainly some applications where threads are a better choice.

If you're sharing things, I would thread. I would not want to  pay the
expense of a process.

It's too bad that programmers are not threading more often.