Gerd Stolpmann skrev:
This is simply nonsense. Different concurrency techniques
> have different problems. True. > For example, in event > handling-based concurrency you do not need locks, hence > you cannot run into deadlocks. Yes you can. We've even had to write design rules to this effect to educate our commercial Erlang programmers. There seems to be a common belief that switching from synchronous to asynchronous communication will eliminate the risk for deadlock, but just like Jon noted, if two threads/processes wait for events from the other processes, they may deadlock*. Using asynchronous programming just makes the deadlock much more difficult to detect, than if the processes communicate synchronously. * In the sense that neither can continue. Deadlock doesn't require the presence of locks at all. Going back to Jon's observation that you cannot exploit multicore with event-based programming, I'm inclined to agree, even though I think that message-passing concurrency is quite suitable for making use of multiple cores (albeit addressing a wholly different problem from data parallelism). The problem with event-based programming is that it doesn't scale complexity-wise, and just as when programming with mutexes, introducing true parallelism just makes it worse. While there may be some simple applications which actually can scale up this way, doing so with more "interesting" concurrency patterns is courting disaster. I could list some juicy examples of important commercial products that are limited to a single core for this very reason, but alas I'm not permitted to. I have to ask you to take my word for it. When scaling up message-passing (or event-based) concurrency, you have to do one of two things: 1) ensure that your code is stable in the face of timing variations and message reordering 2) calculate the entire event/state matrix For hard real-time, you must do (2) anyway. For soft real-time, you don't have to, since a missed deadline can be viewed as a temporary glitch rather than a system error. And (2) suffers from the same problems as model checking - it doesn't scale well. For a phone system (soft real-time), if you pick up the phone and don't get dial tone, you replace the handset, then pick it up again - normally, it will work then. Everyone's experienced this, and it doesn't bother us unless it happens often. Similarly, we can accept if it occasionally takes a few seconds longer than usual. The same behavior would be extremely unnerving - possibly fatal - if the breaks on your car (hard real-time) started exhibiting it. BR, Ulf W _______________________________________________ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
