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
