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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk