Threads vs Processes

[sjdevnull at yahoo.com]

John Henry wrote:
> >
> > Carl,
> >  OS writers provide much more tools for debugging, tracing, changing
> > the priority of, sand-boxing processes than threads (in general) It
> > *should* be easier to get a process based solution up and running
> > andhave it be more robust, when compared to a threaded solution.
> >
> > - Paddy (who shies away from threads in C and C++ too ;-)
>
> That mythical "process" is more robust then "thread" application
> paradigm again.
>
> No wonder there are so many boring software applications around.
>
> 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; MacOS9's cooperative, non-memory-protected system wasn't
inherently worse as long as every application was written properly.
There was nothing inherently non-robust about it!

The key difference between threads and processes is that threads share
all their memory, while processes have memory protection except with
particular segments of memory they choose to share.

The next most important difference is that certain languages have
different support for threads/procs.  If you're writing a Python
application, you need to be aware of the GIL and its implications on
multithreaded performance.  If you're writing a Java app, you're
handicapped by the lack of support for multiprocess solutions.

The third most important difference--and it's a very distant
difference--is the performance difference.  In practice, most
well-designed systems will be pooling threads/procs and so startup time
is not that critical.  For some apps, it may be.  Context switching
time may differ, and likewise that is not usually a sticking point but
for particular programs it can be.  On some OSes, launching a
copy-on-write process is difficult--that used to be a reason to choose
threads over procs on Windows, but nowadays all modern Windows OSes
offer a CreateProcessEx call that allows full-on COW processes.

In general, though, if you want to share _all_ memory or if you have
measured and context switching sucks on your OS and is a big factor in
your application, use threads.  In general, if you don't know exactly
why you're choosing one or the other, or if you want memory protection,
robustness in the face of programming errors, access to more 3rd-party
libraries, etc, then you should choose a multiprocess solution.

(OS designers spent years of hard work writing OSes with protected
memory--why voluntarily throw that out?)