Re: New New Callbacks Uploaded

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-11-27 10:54:46

--- In boost_at_[hidden], Kevlin Henney <kevlin_at_c...> wrote:
> In message <200011240906.BAA16986_at_a...>,
> Michael D. Crawford <crawford_at_g...> writes
> >> And
> >> then there's multithreading.
> >
> >I know it take extra effort, but you can do reference counting 
with 
> >multithreading.  The ZRef reference counted smart pointer in 
ZooLib handles 
> >multithreading correctly.
> 
> The issue is not whether one can count references safely in a multi-
> threaded environment -- we know that this is possible -- but the 
effect
> of the threading and sharing on the thing being counted. There are 
two
> quite different scenarios in which reference counting is employed 
wrt
> memory mgmt (there are many more that have nothing to do with memory
> mgmt, but they're not relevant here):
> 
> (1) To share an object explicitly and track its usage count. This 
is the
> proxy scenario where we have a known placeholder and work on the 
target
> through that. Eg replacing raw pointers and deletes in code with
> shared_ptr.
> 
> (2) To optimise the copying behaviour of a value-based object whose
> representation is internally separated as a handle/body structure. 
This
> leads to sharing and counting of the body, which requires copy-on-
write
> semantics. Eg the standard example of reference counting with 
strings.

(2) does *NOT* require COW.  In fact, COW was never suggested for 
callbacks, nor do I think it appropriate there.  You don't "write" to 
a function pointer or function object (trying to get away from using 
functor, since you say it's no longer the excepted term).
 
> In the (1) ensuring thread safety of the target is the 
responsibility of
> the user and provider of the target. In (2) it is the solely the
> responsibility of the handle provider. As an optimisation it should 
be
> transparent. This means that it should work the same way in the same
> situations. For threading this means that either the body must be
> immutable (deep, physical const) or that it is explicitly 
synchronised
> (mutexes, etc). The latter is a resource-hungry pessimisation, and 
the
> former is only gtee'd if we make immutability a requirement of all
> function objects used with the class. I'm inclined to think that 
this is
> too restrictive.

The problem here comes from internal state of the function object, 
which would need to be handled in a thread safe manner.  Not the same 
thing as COW, but the same issues are involved IRT threading.

> Taken together with the fact that even in a single-threaded 
environment
> (2) is questionable and raises issues, my vote remains with body 
cloning
> rather than sharing.

Well, I don't agree about (2) being questionable, outside of MT 
issues.  COW can be questionable in some (most?) circumstances, but, 
again, COW is a different technique all together.

Bill Kempf