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

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2000-06-06 13:31:34

From: Dietmar Kuehl <dietmar_kuehl_at_[hidden]>
> ...
> Especially for the higher levels of MT-safety, I think it is necessary
> to also have a component level MT-safety guarantee to avoid dead lock
> situations. Something like this:
> 
>   Using multiple objects of possibly multiple classes in the component
>   from multiple threads will not result in a dead lock.
> 
> I think there is no similar guarantee needed for multiple components if
> components do not mutally depend on each other. Where I'm not sure
> about this statement is when using templates or passing objects to a
> lower level component because in this case it is possible that a lock
> in a higher level component is acquired after acquiring a lock in a
> lower level component.
> 
> That is, there is more to MT-safety than preventation of data
> corruption due to multiple threads mutating shared data. It is also
> necessary to prevent or at least detect dead locks. My preference is
> clearly to prevent them in the first place. Personally I'm not aware
> of additional problems with MT-safety but then I have only cursory
> knowledge of MT-safety because I never have used it in more than toy
> programs.

There are large literatures on concurrency and language design, and
concurrency and operating system design, and concurrency and database
design, which I know just well enough to know that I don't know them
as well I should.  But from what I do know, and from my experience
implementing languages and databases, there is a difficult tradeoff
between safety and efficiency, and no silver bullet for deadlock
prevention.  As for deadlock detection, that takes cooperation from
the underlying thread implementation, and is a poor substitute for
prevention.