Re: boost::mutex::scoped_lock conventions

From: Alexander Terekhov (yg-boost-users_at_[hidden])
Date: 2003-05-15 12:53:41

"William E. Kempf" wrote:
[...]
> 1) What is pthread_null() (I can certainly guess on this one, but guessing
> could make a fool of both of us)?

extern "C" pthread_t pthread_null() {
  return pthread_t();
}

> 
> 2) What is pthread_compare() and how does it differ from pthread_equal()
> (again, I could guess)?

extern "C" int pthread_compare(pthread_t tid1, pthread_t tid2) {
  return tid1 < tid2 ? -1 : tid1 > tid2 ? +1 : 0;
}

> 
> 3) What is pthread_hash() (probably the easiest to guess... but again...)?

extern "C" size_t pthread_hash(pthread_t tid) {
  return std::hash<pthread_t>()(tid); // perhaps
}

> 
> 4) Why do *you* think any of these are necessary?

``Why not?'' ;-)

> 
> 5) What "needs to be done in order to provide 'symmetry' with respect to
> <thread>/boost.thread stuff"?  My participation in the Open Group?  My
> understanding of what they're doing?  The inclusion of the above functions
> to POSIX threads?

Well, pls see above and below.

> 
> This is pretty much the first time 

I've 'mentioned' it here before -- in the 'Pro-"pthread_null/compare/hash" 
lobbying association' sig.

>                                    I've heard of these functions, so
> asking me to champion them with out more meat is still not the best form
> of "saying what you mean".

But it's somewhat better than before, right? ;-)

> 
> BTW: If the above functions are what I think they are, I can provide them
> in Boost.Threads with out anything being changed in the POSIX standard.

We need a POSIX.C++ standard, that's why you and others should join 
the Austin group. (check out some messages on the "Austin Off Topic 
Discussion" reflector)

> (In fact, the only one not provided for in the implementation in
> thread_dev is thread_null(), assuming I'm making the right guesses as to
> what these functions are.  It means specifying some requirements on the ID
> in the documentation, but the implementation already provides this.  I've
> debated thread_null(), as I do see uses for it, but that would require a
> backwards incompatible change to the interface, so I've got to make the
> decision carefully.)  So there's not a lot of reason for me to champion
> them in the Open Group, though there is reason for me to be interested in
> any debate or resolution that occurs there.

http://tinyurl.com/buj9

regards,
alexander.

--
typedef std::kinda_dumb_thread_ptr pthread_t;