Boost logo

Boost :

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
>We obviously agree that at least these operations shall be provided:
>class thread_id
> 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
>of processes and threads. This requirement is at least from my viewpoint
>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
>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

MSN Photos is the easiest way to share and print your photos:

Boost list run by bdawes at, gregod at, cpdaniel at, john at