Trevor,
I agree with you, that at the end you have similar
problems and benefits in both cases. The main difference
is that in the case of multiple processes it is harder to
accidentally access the same data from multiple
processes. If you are used to sequential programming, it is
easier to get it wrong with multiple threads than with
multiple processes. It gets worse if you are using object
oriented programming because it is often hard to control
which thread accesses which objects....
The difference is: with threads you have to take action to
protect your data structures from being accessed by other
threads. With multiple processes, you have to take action to
access the data of the other process. That *is* a difference.
http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf
Michael
Trevor Talbot wrote:
On 10/4/07, Michael Scharf <[EMAIL PROTECTED]> wrote:
Trevor Talbot wrote:
It's just that the classic Unix environment encourages multiple
processes, and the Windows environment encourages multiple threads,
when you have parallel tasks to perform. There aren't any fundamental
issues that prevent you from using either method in either
environment, as appropriate.
There are! Multiple threads act in the same address space and that is the
cause of many problems. Two processes have separated address spaces
exchange of information between the processes has to be designed
explicitly.
Er, that isn't really a response to my comment. I was saying that
both methods work on both platforms.
In the general case, people need to realize that the issue is not
about *threads* (the implementation), but about *parallel execution*
(the model). Multiple threads vs multiple processes is merely an
implementation detail of the same basic concept, which is that you
have your program doing multiple things to the same data at the same
time. The synchronization issues of processes and threads are the
same. The limitations on data manipulation are the same. The
problems defining a consistent execution model are the same.
Speaking more to your comment, shared memory is a common IPC
mechanism, and I've seen people screw that up just as badly as when
they use threads. File I/O is another major area of mistakes. The
only relevant difference between the two methods is that processes
naturally lead people toward object-oriented message-passing types of
design, while threads naturally lead people toward cooperative
shared-state types of design. That's probably why people get so hung
up on the implementation detail of threading when they really need to
be stepping back and thinking about the design.
Again, the question people need to answer is whether having their
program attempt to do multiple things on the same data at the same
time is fundamentally a good idea or not. Processes vs threads isn't
even part of that question; it's what you look at when you've already
decided that this model of parallel execution IS what you want to do.
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
--
http://MichaelScharf.blogspot.com/
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
