Boost logo

Boost :

From: williamkempf_at_[hidden]
Date: 2001-11-29 10:28:19


--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: <williamkempf_at_h...>
> > --- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> > > It is my opinion that it belongs there as well, but Bill Kempf
did
> > not agree
> > > when I brought this up.
> >
> > This simply isn't true ;).
>
> Sorry.
>
> > I don't think that an atomic integer type
> > belongs there... at least not with out a lot of very careful
> > consideration about what such a type means. However, an atomic
> > reference counter (actually, a MT safe reference counter would be
a
> > better description) is very much relevant to Boost.Threads. Just
not
> > at this stage in it's life cycle.
>
> This stage of the shared_ptr life cycle, however, needs an atomic
reference
> count. shared_ptr<thread> is an idiom recommended by the
Boost.Threads
> rationale, after all.
>
> So the question is where should it go. In boost/, in boost/detail/
or in
> boost/thread/ ?

Now that's a more valid question. I was going to address it, but I'm
not sure what the answer is. If you or someone else submits a well
thought out and designed implementation for this concept I'm willing
to merge it with Boost.Threads today, with only a couple of
reservations. I've got three other concepts I feel are more
important to Boost.Threads (though obviously you've got a legitimate
need that you find more compelling) that will take some time to flesh
out, and I'm at least a little concerned with rushing in this
particular concept before the others are ready (and shared_ptr<>
needs this sooner than those will be done). Also, putting the
concept in Boost.Threads will create that dependency on the
Boost.Threads library that you (probably rightfully) pointed out
could be a reason for someone to reject using shared_ptr<>.

I guess what I'd "recommend" is making the ref-counting a template
policy parameter and provide a detail policy that rolls it's own
thread-safe implementation. Conditional compilation can
automatically select this policy class when BOOST_HAS_THREADS is
defined. Then Boost.Threads can use this as the basis of a thread-
safe ref-counting implementation later, and we can decide on how to
deal with the library coupling at that point.

Thoughts?

Bill Kempf


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk