Re: detail::atomic_counter

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