Re: [boost] Thread locals

From: Detlef Höffner (Detlef.Hoeffner_at_[hidden])
Date: 2002-04-05 14:19:34

> 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?

William, I don't think that's exactly what I've said:
"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,"

This is a statement about the effect of the operator<< and nothing more.
Well, I admit that the obvious implementation is to use exactly that id
internally.-)

> 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.

OK, then we can probably live with Beman's suggestion:

"Type thread_id must meet the requirements given here, but is otherwise
implementation defined. Implementations are encouraged to give thread_id
the same type and values as in the underlying native thread system, if
possible."

That sounds quite reasonable to me. What do you think?

Regards

Detlef

----- Original Message -----
From: "William Kempf" <williamkempf_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, April 05, 2002 2:09 PM
Subject: RE: [boost] Thread locals

> >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
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>