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