Thread state

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-08-30 07:02:08

From: "William Kempf" <williamkempf_at_[hidden]>
> From: "Peter Dimov" <pdimov_at_[hidden]>
> >Exactly. There is one more thing to a 'fully compliant' current() - it
has
> >to return a reference to the same thread object (if the design exposes a
> >thread object, of course) when invoked several times from the same
thread -
> >but I believe this is solvable.
>
> This is a requirement from where?

This is the primary requirement of the "alternative" design. Every thread
has an associated thread object that is guaranteed to persist for the
lifetime of the thread. This makes it possible to store thread state
directly in the thread object.

> The only requirement is that the objects
> encapsulate the same thread state (maybe you meant the state to be the
> "thread object" you talk about exposing... but if that's the case we need
to
> be very careful with our terminology since we have a "thread object"
that's
> not the same thing as the "thread state").

Right. Talking about the current design, the thread state is not stored in
the thread object (boost::thread.) In a previous post you commented that
"this is what TLS is for." However, thread state is sometimes manipulated
from a different thread. To pick a simple example, let the thread state be
'bool canceled.' When thread A calls B.cancel(), A has to access B's state
to set the canceled flag to true. This means that both the thread object and
a TLS slot must store a reference to the thread state.

This is essentially a hidden thread_ref layer that manages the thread state.

--
Peter Dimov
Multi Media Ltd.