RE: [boost] Thread locals

From: Hoeffner, Detlef (Detlef.Hoeffner_at_[hidden])
Date: 2002-04-05 02:04:06

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 );
};

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. 

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

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

Detlef

-----Original Message-----
From: Moore, Dave [mailto:dmoore_at_[hidden]]
Sent: Donnerstag, 4. April 2002 22:16
To: 'boost_at_[hidden]'
Subject: RE: [boost] Thread locals

> >Bill, on pthreads-win32, it's a pointer to a struct 
> pthread_t_.  Without
> >checking the Open Group specs, my suspicion is that you are 
> technically
> >correct that it's an opaque type, but that on most 
> implementations people
> >are used to getting away with using:
> >
> >pthread_t pt;
> >printf("%d",pt);
> >// or
> >printf("%p",pt);
> 
> Oh, I'm quite certain that most platforms define pthread_t as 
> a pointer to 
> some struct type.  But I'm also certain that the type is 
> specified in the 
> standard as opaque, and thus the example usage you just gave 
> results in 
> undefined behavior and is non-conforming code.

I'm actually agreeing with you!  I just think that alot of people are used
to using pthread_t carelessly, which lets them use it just like a 32 (or 64)
bit integer, etc.

This is, of course, exactly the kind of place that Boost.Threads will make
concurrent programming less error-prone and more portable.  

Thanks,
Dave

> Bill Kempf
> williamkempf_at_[hidden]
> 
> 
> _________________________________________________________________
> Chat with friends online, try MSN Messenger: http://messenger.msn.com
> 
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
> 
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost