MT guarantees (was: RFC: Multithreading design constraints)

From: Dietmar Kuehl (dietmar_kuehl_at_[hidden])
Date: 2000-06-06 12:34:41

Hi,

--- John Maddock <John_Maddock_at_[hidden]> wrote:

Excellent start! The levels of thread safety guarantees give us the
focus on what we actually want to achieve: At least I wasn't aware of
this concept and I felt uncomfortable with varying definitions of
thread safety because I normally want to achieve only rather low levels
while other often want to achieve much higher levels. Of course, this
is due to the fact that I'm normally implementing fairly low level
abstractions (eg. streams and containers) while others are implementing
higher level abstractions.

Before going into details of interfaces to be used to be used for the
maintainance of the thread safety guarantees, we should focus on the
definition of these guarantees and their orthogonal aspects plus idioms
how to achieve the respective guarantees. I haven't seen the concept
of thread safety guarantees (beyond rather primitive forms like
"MT safe" and "MT unsafe") and thus I'm not sure whether we can build
on much prior knowledge in this area. However, there is definitely
stuff with respect to the idioms which actually address different
levels of thread safety guarantees (without being aware of these levels
at all...).

The discussion on the list unfortunately got distracted from the basic
issues jumping on the technical stuff. Yes, I would also love to start
this and actually it seems that it is fairly easy to come up with a
basic locking mechanism (a mutex class, a lock class, et voila).
However, when implementing components I would like some guidance to
decide which thread safety guarantee I should provide and how I should
go about to achieve this. Personally, I think I have the necessary
knowledge but I would like to see that I'm actually right and also I
think that people should not be required to get the contemporary
literature on every detail of implementation to be in the position of
implementing something.

Concerning the discussion itself, I think it is fairly hard to follow
because lots of different issues are discussed under the same subject
and sometimes different issues are discussed in the same message.

That much for the organizational stuff... A few comments on the
technical stuff:

> Level 0:
> (Unsafe)
> At this level using unrelated instances of an object in separate
> threads is not thread-safe, the objects can not be made thread safe
> even by applying an external lock (typically this effects objects
> that share unprotected non-constant global data).

Note that a program using an MT-unsafe component cannot have a higher
MT-safety level except when the MT-unsafe component only uses MT-strong
components! Thus, this level of MT-safety should best be avoided.

> Unrelated instances of the object can be safely used in separate
> threads (by unrelated I mean "not a copy of").

We should also be careful with terms "object" and "class": The above
sentence should probably be "Unrelated instances of the class can be
safely used in separate threads." Objects have an identity and it makes
no sense to speak of "unrelated instances of the object" because all
instances would share the same identity.

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.

=====
<mailto:dietmar_kuehl_at_[hidden]>
<http://www.dietmar-kuehl.de/>

__________________________________________________
Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!
http://photos.yahoo.com