From: William Kempf (williamkempf_at_[hidden])
Date: 2002-04-05 08:09:45
>From: "Hoeffner, Detlef" <Detlef.Hoeffner_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:
> bool operator==( const thread_id& id ) const;
> bool operator!=( const thread_id& id ) const;
> bool operator<( const thread_id& id ) const;
> 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
>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
>BTW, Regarding the representation of pthread_t at least under Linux and
>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.
MSN Photos is the easiest way to share and print your photos:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk