On Monday 19 May 2008 15:09:04 Gerd Stolpmann wrote: > On the contrary: Shared memory parallelization has the fundamental > disadvantage that you cannot reason about it,
I have been reasoning about shared memory parallel programs for many years. > and so the only way of checking the quality of the code is testing. I often assess the correctness of my parallel codes just by reading them. > Event handing concurrency, while not giving you parallelization, is > basically sequential programming, and it is possible to reason about such > programs. Programs are parallelized in the interests of efficiency. Event handling concurrency is orders of magnitude less efficient in the context of CPU-intensive tasks that are not embarassingly parallel so it is not an alternative. > With "reasoning" I don't necessarily mean formal techniques. The more > frequent case is that the programmer thinks about the program guided by > the laws of logic. Then it is a subjective belief. > The impossibility to do this with truly parallelized code is an > important source of bugs, so I would say this code inherently more > buggy. Your remit is concurrency and not parallelism. > > i.e. you have an additional > > source of bugs, without removing the problems that are inherent > > in concurrency (e.g. deadlocks, livelocks, fairness ...). > > This is simply nonsense. Different concurrency techniques have different > problems. For example, in event handling-based concurrency you do not > need locks, hence you cannot run into deadlocks. Two agents cannot proceed because they are waiting on events from each other => they are deadlocked even though there are no mutexes. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e _______________________________________________ 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
