Re: New New Callbacks Uploaded

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-11-22 15:27:19

--- In boost_at_[hidden], Douglas Gregor <gregod_at_r...> wrote:
> On Wed, 22 Nov 2000 19:41:22 +0200
> "Peter Dimov" <pdimov_at_m...> wrote:
> 
> > From: "Douglas Gregor" <gregod_at_r...>
> > 
> > > 3) We have three different sets of semantics for callback 
copying -
> > explicit reference counting (which your implementation uses), 
shared_ptr
> > reference counting (which I use), and cloning (Peter Dimov's 
function_ptr).
> > Cloning is safest (but inefficient), whereas shared_ptr is 
currently not
> > thread-safe and explicit reference counting could easily be made 
safe. What
> > is the goal of the Boost callback library regarding thread safety 
vs.
> > efficiency?
> > <
> > 
> > Note that, as Kevlin Henney already pointed out, there's more to
> > thread-safety than the reference counting.
> > 
> > callback<void> c(F());
> > callback<void> c2(c);
> > 
> > // thread 1
> > 
> > c();
> > 
> > // thread 2, at the same time
> > 
> > c2();
> > 
> > Even in a single thread, the cloning and counted callbacks are 
different.
> > It's not only a thread-safety vs. efficiency tradeoff.
> > 
> > We'll have to decide which behavior we need. Is the efficient 
copy so
> > important? Callbacks are rarely copied, in my opinion. However, a 
reference
> > counted callback has the nice property that its copies are exactly
> > equivalent even when the pointed-to function object has state; 
some STL
> > algorithms require this.
> 
> Perhaps this is a boon to a reference-counted callback. Instead of 
relying on the callback to order the c() and c2() calls above, supply 
a functor adapter which handles this.

To be honest, I don't totally follow what problem exists here.  I 
don't *think* ordering was the issue being addressed, because 
function pointers would behave in the exact same way.  I *think* that 
instead he was addressing how state information contained within a 
full functor could have serious repurcussions during execution of 
both instances of the shared functor.  I personally don't think that 
a cloning version addresses this issue in the proper way, though 
that's just a point of view swayed by the preference for ref-
counting.  *shrug*

> This doesn't solve the non-thread-safety in shared_ptr itself, but 
I believe William Kempf has that solved already?

Partially.  I've got a boost::shared_ptr that I *think* is thread 
safe... but I'm not expert enough to trust myself on this one.  
However, it's not a good solution in general, since it adds overhead 
to shared_ptr even for instances where nothing will be shared across 
thread boundaries.

Bill Kempf