Bryan Sant wrote: > I'm not disagreeing that there are two distinct issues with > concurrency. My earlier post made the suggestion of using threads in > tandem with a high-level language that provides proper memory > protection and heap data scope isolation. Given this situation I find > that the built-in protection of OS processes is unneeded. There are > trade-offs with both approaches - child-processes and threads.
Threads provide no way to enforce a communication protocol. You can't write an interface specification that states all of the ways a parent thread will talk to a child thread, since threads make it too easy to manipulate inter-thread state out of band. Even if you choose rules for inter-thread communication and stick to them, future maintainers of your code might accidentally violate those rules, receiving no warning for doing so. Your own refactoring could break your rules. Breaking the rules can lead to intermittent bugs such as race conditions and deadlocks. These bugs are the kind that only show up under heavy load, and thus cost a lot of money to fix. Using child processes forces you to define a communication protocol and strongly encourages future maintainers to modify that protocol rather than manipulate state out of band. This mostly eliminates a whole class of race conditions. It does not eliminate deadlocks, but you can fix deadlocks by analyzing the interprocess communication. > I don't believe that Java's threading model is the best that could be, > but I do find it more than worthy to utilize in the face of existing > alternatives today. Given Java's model (an others who have similar > capabilities), I don't find any virtues in the child-process model of > concurrent programming compared to threads. I've seen what other programmers have done to my code. They may be brilliant coders, but their style is different, so they don't recognize some of the patterns and accidentally break them. If a broken pattern leads to race conditions, then the problem often only shows up under load. I've personally broken someone else's inter-thread communication pattern without knowing it, and the breakage led to a month of diagnostic effort on a production system by 4-5 developers. It turned into a serious risk to the business. Today I prefer concurrency models that enforce a communication protocol, unlike threads. Shane /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
