Re: [boost] Re: New New Callbacks Uploaded

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2000-11-27 15:57:44

I've not been following this closely, but Kevlin and I are working on
and operator() for shared_ptr, which would make it easy to add reference
counting to a cloning implementation.

----- Original Message -----
From: Douglas Gregor <gregod_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, November 27, 2000 1:57 PM
Subject: Re: [boost] Re: New New Callbacks Uploaded

> On Thu, 23 Nov 2000 14:45:57 -0000
> "William Kempf" <sirwillard_at_[hidden]> wrote:
>
> [snip]
> > *shrug*
> >
> > I'm *slightly* leaning towards cloning instead of ref-counting at
> > this point.  In general it's safer, and as pointed out, when this
>
> In general cloning is safer, but statics, pointers, references, and data members are all unsafe even with cloning. My general fear
is that we are guaranteeing too much by calling cloning safe in multithreaded environments (and then listing all of the exceptions).
Instead, I would suggest that we use reference-counting and explicitly state that the function object must itself be thread-safe to
guarantee thread safety. I also expect that any Boost threads library would contain a function object adaptor to mutex any function
object. This makes it the user's responsibility to make a function object thread-safe, but at least it is stated that it is never
safe to assume thread-safety.
>
> Also, I've been trying to consider how often cloning would be more thread-safe than ref-counting, and as far as I can see these
are the most common uses of function objects:
> 1) Wrapping free and member functions (e.g., ptr_fun)
> 2) Performing some operation on the arguments and returning the result (e.g., negate, plus)
> 3) Binding arguments (e.g., bind1st, bind2nd, lambda)
>
> #1 and #2 won't be more safe using cloning. #3 is safe because the bound arguments are immutable anyway. Other function object
types may be safer with cloning, but I doubt these occur with great frequency.
>
> > implementation becomes detrimental you can wrap it in a ref-counting
> > proxy (whether it be shared_ptr or some other proxy).  Going the
> > other way, for example if it's deemed too dangerous for threading
> > use, is not really possible.
>
> This is case where the desire to support multithreaded code is detrimental to single-threaded code. Either the degradation is in
performance, or the degradation is in the remedy to the performance problem - using shared_ptrs makes for ugly usage of the callback
code.
>
> Doug Gregor
>
>
>
>
>
>