From: Gary Wright <gwtmp01@...>
Date: 2007-05-10T04:20:53+09:00
Subject: Re: basic threading question: can ruby use real threads?


On May 9, 2007, at 2:57 PM, Marcin Raczkowski wrote:
> I didn't say it makes use of POSIX threads - i just recomended it  
> becouse they
> are well ... faster.
>
> only thing right now that'll let you use botht procesors is fork

Just my opinion but my default choice would be fork when I need
concurrency rather than threads.  The main reason is that it forces you
to be explicit in how you structure the communication between processes.
One process can't inadvertently change the state of another.
On a multi-processor box you'll get IO multiplexing and real CPU
concurrency automatically with fork.

Some problems can't be partitioned easily into separate addresses  
spaces,
in which case threads are a better choice.  Even then I might consider
using shared memory among cooperating processes first.

I realize that the Unix fork/exec model of processes doesn't quite apply
in the Windows environment. Anecdotal evidence makes me think that
Windows programmers tend to reach for threads as a multi-tasking  
solution
more often than Unix programmers.

One more observation.  The desire for real concurrency using multiple
processors is great for problems that can be cleanly partitioned, but if
you have a problem that requires concurrent access to shared data then
you'll have to keep in mind the memory/cache contention that will be
created when processing is distributed across multiple processors (via
processes or threads).

Gary Wright