From: Greg Colvin (gcolvin_at_[hidden])
Date: 2000-06-06 17:59:45
From: David Abrahams <abrahams_at_[hidden]>
> From: "Greg Colvin" <gcolvin_at_[hidden]>
> As for deadlock detection, that takes cooperation from
> > the underlying thread implementation, and is a poor substitute for
> > prevention.
> Seems to me that if we provide an API for threading, and clients agree not
> to subvert it by using the underlying threading API directly, we could
> detect deadlocks for them. No?
Perhaps, but it will require a much "thicker" wrapper. Also,
requiring "non-subversion" means you can't coexist with modules
that use the underlying threading API.
As a Java implementer I can assure that maintaining consistent
behavior of a threading API across varying underlying thread
facilities is no fun. That may just be because the Java API is
no good, but I haven't seen a better one proposed here.
For these reasons I still prefer sticking with the more tractable
problem of assuring atomicity.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk