Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-09-24 15:22:10

From: <williamkempf_at_[hidden]>
> --- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> > From: <williamkempf_at_h...>
> > > --- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> > > > class thread
> > > > {
> > > > unsigned long id() const; // uniquely identifies the thread
> > > > };
> > > >
> > > > What do you think?
> > >
> > > I think it's a pain in the @$$ to implement on POSIX ;).
> >
> > I think that it's doable. You'd need a get_next_id() thread safe
> function.
> Never said it wasn't doable. In fact your solution actually existed
> in earlier Boost.Threads code while I toyed with this method. There
> are problems with this, such as the fact that it's at least
> theoretically possible to exhaust all such id's if you don't track
> which id's no longer have active threads.

int64_t? ;-)

> You can't use a thread inside a std::map<> because it's not
> copyable. That's why I said I realized that there was not enough
> functionality for collation but that there wasn't much need for it.
> Even if we fully provided collation it's not useful for your
> std::map<> because we can't copy it. Wrap it in a thread::ref or use
> pointers instead and you've "automagically" got a value that is
> collatable... the pointer.

Not exactly because I don't have a way (within boost.threads) to obtain the
pointer for the current thread; this can be worked around but this leads to
a full-blown thread::ref anyway. ;-)

> As for errorcheck mutex
> implementations... you don't need full collation you only need
> equality comparison, which boost::thread has already got.

But I need something to compare to. Are you suggesting that I store a
boost::thread object inside the mutex, just for comparison purposes? Is this
the 'official' Boost.Threads way?

Peter Dimov
Multi Media Ltd.

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