Re: [boost] Re: New New Callbacks Uploaded

From: Douglas Gregor (gregod_at_[hidden])
Date: 2000-11-23 10:59:23

On Wed, 22 Nov 2000 20:27:19 -0000
"William Kempf" <sirwillard_at_[hidden]> wrote:

> --- 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*

My impression was that Peter Dimov wanted the callback to prevent multiple concurrent invocations of the callback, but I don't see how cloning solves this problem either. In fact, reference counting seems the better solution in this case because the functor being called can manage concurrency.

> > 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
> 
> 
>