RE: [boost] Thread locals

From: William Kempf (williamkempf_at_[hidden])
Date: 2002-04-05 08:09:45

>From: "Hoeffner, Detlef" <Detlef.Hoeffner_at_[hidden]>
>Reply-To: boost_at_[hidden]
>To: "'boost_at_[hidden]'" <boost_at_[hidden]>
>Subject: RE: [boost] Thread locals
>Date: Fri, 5 Apr 2002 09:04:06 +0200
>
>
>To identify a good solution regarding thread_id we need to
>list requirements we would like to be fulfilled and then choose from
>different possibilies the one that fits best.
>
>The major question probably is: What kind of operations shall the type
>provide?
>We obviously agree that at least these operations shall be provided:
>
>class thread_id
>{
>public:
>    bool operator==( const thread_id& id ) const;
>    bool operator!=( const thread_id& id ) const;
>    bool operator<( const thread_id& id ) const;
>    friend
>    std::ostream& operator<<( std::ostream& out, const thread_id& id );

You missed (and I think this at least as important as the above):
     thread_id(const thread_id& other);
     thread_id& operator=(const thread_id& other);
>};
>
>Another requirement I would like to see fulfilled is that the output
>of the thread id is identical to the thread id the underlying system uses,
>e.g. equal to thread ids that are shown in debugerrs or tools that show
>trees
>of processes and threads. This requirement is at least from my viewpoint
>much
>more important than having a unique internal representation of thread_id on
>different platforms. I mainly care about the interface that is provided.

I see a contradiction in what you just said.  How can you care mainly about 
the interface, but think that having the implementation use the native 
identifier is more important then having a unique internal representation?

In any event, if I could portably provide an implementation that gave the 
same id as the native tools, I'd do so.  But I don't think I can do this 
with POSIX.

>And the third thing that should be considered are probably performance
>issues.
>Access to the current thread id should be fast.

Using the TLS slot will be fast... because the result will be cached in the 
thread object.

>BTW, Regarding the representation of pthread_t at least under Linux and
>Solaris 7
>they are integral types.

Which is likely common, but I don't believe gauranteed.  If POSIX gauranteed 
this there'd be no need for pthread_equal().  However, I'll do the research 
on this one before making any final decisions.

Bill Kempf
williamkempf_at_[hidden]

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx