[boost] Some questions on Boost Threads

From: Parameswaran, Vinod (vparameswaran_at_[hidden])
Date: 2004-10-01 02:26:54

Hello list,

 

My name is P. Vinod and I am currently debugging an application that was
initially written using single thread but later ported to multithreads.
The threading has been done using Boost library functions. I am new to
Boost library and would like to clarify some of my doubts with you.
Please reply to vparameswaran_at_[hidden]

 

I have been studying William Kempf's documentation on Boost threads
(http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/threads
.html) and all my questions are based on the references therein:

 

1. <begin quote>

The template thread_specific_ptr
<http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/class.b
oost.thread_specific_ptr.html>  is useful in the following cases: 

*	An interface was originally written assuming a single thread of
control and it is being ported to a multithreaded environment. 

<end quote>

Is there any other way by which you could port a single threaded
interface to multithreaded interface using Boost threads? My debugging
approach will be based on your answer to this question.

 

2. Does anyone have some examples of scenarios wherein each of these
classes could be used (would even appreciate reference to relevant
docs., if any):

            a. barrier

            b. condition

            c. thread_group

            d. thread_specific_ptr

 

3. Assumption: In the case of a condition object, ONLY THE FOLLOWING
METHODS could be used to specify the wait condition:

 

a.       template<typename ScopedLock, typename Pred> void
wait(ScopedLock& lock, Pred pred);

b.       template<typename ScopedLock> bool timed_wait(ScopedLock& lock,
const bool::xtime& xt);

c.       template<typename ScopedLock, typename Pred>bool
timed_wait(ScopedLock lock, Pred pred);

 

Is this correct?

 

4. <begin quote>

 

            A thread object has an associated state which is either
"joinable" or "non-joinable".

 

 <end quote>

 

Is this state indicated using a type or is merely implied by whether the
default or the parameterized constructor is called for the creation of
the thread object?

 

5. Could anyone give examples of the use of void join() and void
yield()? (Would even appreciate reference to relevant docs., if any)

 

6. <begin quote>

Template thread_specific_ptr stores a pointer to an object obtained via
new on a thread-by-thread basis and calls delete on the contained
pointer when the thread terminates. Each thread initially stores the
null pointer in each thread_specific_ptr instance.

 

   <end quote>

 

Does each thread create its own 'object' referred to here and modify its
thread_specific_ptr class by invoking void reset(T* p=0) ?

7.  <begin quote>

            The template thread_specific_ptr is useful in the following
cases:

*	Each thread of control invokes sequences of methods that share
data that must be logically accessed through a globally visible access
point, but are physically unique for each thread, instead of being
explicitly passed. 

<end quote>

<begin quote>

Template thread_specific_ptr stores a pointer to an object obtained via
new on a thread-by-thread basis and calls delete on the contained
pointer when the thread terminates. Each thread initially stores the
null pointer in each thread_specific_ptr instance.

 

   <end quote>

>From the above statements, I could draw the inference that the
thread_specific_ptr object stores the data that is shared amongst the
various methods invoked from within a thread; however this data is not
shared amongst threads and is unique for each thread.

<begin quote>

thread_specific_ptr construct/copy/destruct

1.           thread_specific_ptr();

Requires: The expression delete get() is well formed.
Effects: A thread-specific data key is allocated and visible to all
threads in the process. Upon creation, the value NULL will be associated
with the new key in all active threads. 

  <end quote>

 <begin quote>

1.           ~thread_specific_ptr();

..... For this reason you should not destroy a thread_specific_ptr
<http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/thread_
specific_ptr.html>  object until you are certain there are no threads
running that have made use of its thread specific storage.

<end quote>

The above statements seem to contradict the previous quotes, in that a
thread-specific data key is visible to all the threads in the process
and thread-specific storage is shared amongst multiple threads. Could
anyone dispel the apparent ambiguity here? Also, what is the concept of
"data key"?

Gratefully appreciate your time and advice on the above.

Vinod