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] -----------------------------------------------------------------------------
