Boost logo

Boost :

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-11-23 09:39:08


--- In boost_at_[hidden], Kevlin Henney <kevlin_at_c...> wrote:
> In message <v03110703b6421d10642f@[153.32.222.4]>, Jesse Jones
> <jejones_at_a...> writes
> >>This means that we have three choices:
> >>
> >>(1) Impose this restriction.
> >
> >In other words the responsibility for making the functor call
thread safe
> >relies on the functor itself. The functor can do this by not
having any
> >mutable state or by using thread synchronization objects.
>
> Exactly. It would be part and parcel of the function object
> requirements.

Except that the requirements don't always exist. That's the nasty
part about thread safety. It costs in terms of memory and
performance. This cost can be prohibitive for a wide range of uses
(not all programs even have multiple threads, and even those that do
have large areas of code that are logically protected from thread
safety issues because they don't share data). So, I don't know if I
like this approach.

> >>(2) Separate out the mutability aspect into a separate class, ie
> >>function_ptr and const_function_ptr. The former is not reference
counted
> >>and the latter requires deep, physical const-ness but can be
reference
> >>counted.
> >
> >Or perhaps the body copy semantics can be special cased more
intelligently.
> >Maybe using some sort of traits mechanism. For example, it's
pretty silly
> >to clone a functor wrapping a method call.
>
> I presume that the default would have to err on the side of safety.
> Although is no need to copy member or non-member function wrappers,
> there is an issue over the amount of specialisation involved to
meet the
> expectations, eg pretty much all function object types in the
standard
> and I guess many parts of the Lambda library. How much coupling do
we
> want? I think that the amount of configuration involved would put
me off
> this solution.

You need to strive for no coupling, else you infringe on functor
libraries of the past and future.
 
> >>(3) Not implement reference in the function_ptr at all.
> >>
> >>IMHO, (3) is now the most reasonable option. If we wish to have
> >>reference counting of an object, then we can provide it using a
smart
> >>pointer. The only problem with this is that most smart pointers,
> >>including shared_ptr, are restricted to the narrow view of
supporting
> >>only operator* and operator-> wrt pointer-ness.
> >
> >Interesting idea, although it seems like the utility of the non-
copyable
> >callback is pretty limited.
>
> There's no restriction of the copyability. If you want reference
> counting, and you want to manage the risks of inter-thread sharing,
you
> would write something like
>
> shared_ptr< function_ptr<void> > s(new_function_ptr(f));
> ...
> s();

Except that shared_ptr doesn't have an operator() ;). I don't think
you can add it, either, as you don't know how many parameters the
wrapped functor will take. Not a big deal, though, since (*s)();
will work.

Bill Kempf


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk