On Mon, May 19, 2008 at 04:09:04PM +0200, Gerd Stolpmann wrote: > 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.
Mostly. You do however need to pay attention to which functions can schedule. Thus code like this may need a lock: let f () = let a = !global_structure in call_a_function_which_can_schedule (); global_structure := a + 1 For small programs this is manageable, but for large programs tracking functions which can schedule can be intractable. Particularly it's a problem when some fundamental function changes (eg. a fundamental function calls a logging library which changes from logging to local disk, to logging remotely -- hence starts to call schedule). My pthrlib library[1] has locks for this reason, and programs which use the library sometimes use the locks, although mostly they aren't needed. Rich. [1] Google it ... another contribution to the world of lightweight non-preemptable threading libs. -- Richard Jones Red Hat _______________________________________________ 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