Re: [boost] New New Callbacks Uploaded

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-11-25 10:13:39

In message <200011240906.BAA16986_at_[hidden]>,
Michael D. Crawford <crawford_at_[hidden]> 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.

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.

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.

Kevlin
____________________________________________________________

  Kevlin Henney                   phone:  [phone]
  Curbralan Limited               mobile: [phone]
  mailto:kevlin_at_[hidden]     fax:    [phone]
  http://www.curbralan.com
____________________________________________________________