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