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

Bryan Sant bryan.sant at gmail.com
Wed Oct 25 11:51:22 MDT 2006


On 10/19/06, Levi Pearson <levi at cold.org> wrote:
> 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

I always just go with threads.  But then again, I do a lot of desktop
software, where interaction between components is frequent and shared
memory is more efficient, reliable, and convenient than message
passing via pipes or some other IPC mechanism.  I'm not saying that
Levi's points aren't valid, on the contrary, they are.  Memory space
protection provided by a process is valuable...  Valuable if you're
using C, or some other language that can stomp on or leak memory.  If
you're using a language with memory management (Perl, C#, Java, Lisp),
then the protection provided by processes has little value and some
down sides.  I find the protection provided by processes to be
overrated.  You can achieve a much more natural programming model by
using threads and semaphores, than processes and marshaled messages.
I would complain that forking has memory overhead too because you have
to make a complete copy of your stack/heap for the forked processes,
but Linux is sweet and employs a copy-on-write technique where the
forked process uses the parent's memory until it tries to overwrite a
value (then a copy is made).

Am I crazy, do other non-C/C++ developers really like processes more
than threads?

-Bryan



More information about the PLUG mailing list