[gclist] Multi threaded reference counting

[James McCartney]

At 1:03 PM -0800 1/19/97, Henry G. Baker wrote:

>I did a little bit of work on this problem, and the general solutions
>go something like this.  Each processor is given a memory location that
>it 'owns', in the sense that everyone else promises not to write into it,
>but only to read from it.  All processors have read access to everyone
>else's 'owned' location.

While this might be a solution, it doesn't seem suited for
an SMP OS like the BeOS where no processor owns anything and any
memory is available to all. Processes are not bound to processors so
there is no notion of code being run on a certain processor; a thread
can migrate freely between processors.

>The 'owned' locations are used as a kind of mailbox where a processor
>posts information about its current state, and everyone else can read
>it.  This convention provides a kind of polled broadcasting facility.

The overhead of posting requests for particular locations is in my
estimation much greater than the fix I proposed for the race condition.

Again, the setup I proposed requires no synchronization, no locks,
no blocking at all. What it imposes is that objects whose reference
counts are zeroed because they were overwritten must be passed to
each thread. Threads can process their list at a safe point, during
allocation would be a good time. They pass on garbage to the next thread.
Objects whose refcounts are no longer zero are dropped from the list.
Once an object has been processed by all threads and its refcount is
still zero then it is truly free. Objects may be freed immediately if
their last refcount is consumed by being dropped from a thread's stack, or
by being cleared from an already dead object, since no other threads
can get at them anymore.

   --- james mccartney     james@clyde.as.utexas.edu   james@lcsaudio.com
If you have a PowerMac check out SuperCollider, a real time synth program:
ftp://mirror.apple.com//mirrors/Info-Mac.Archive/gst/snd/super-collider-demo.hqx