Re: [boost] MT guarantees (was: RFC: Multithreading design constraints)

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.