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