[gclist] A problem with the Baker treadmill.

James McCartney james@clyde.as.utexas.edu
Mon, 13 Jan 1997 10:51:25 -0700


At 11:03 AM -0600 1/13/97, Charles Fiterman wrote:
>I was updating our Treadmill collector to work in a
>multi threaded environment when the problem with
>this kind of write barrier struck me hard.
>
>The write barrier moves stuff from the white queue
>to the grey queue. This means locking those queues
>or locking the whole collector or something like that.
>While moving things from one queue to another is
>acceptable overhead that lock is way over the top.


Thats exactly what I'm doing and have run against.
If you're using a treadmill per size class then
you're only locking a treadmill for one size of object,
but still..

You need a lock on either the object or the queue to even
just check the color of the object. Otherwise the color may change
out from under you. Am I wrong? Hope so.

A lock isn't real expensive unless there is an actual collision.
You can atomic or a flag and if it was already set only then try to
acquire a semaphore.

In my system the write barrier doesn't wind up actually needing to
move objects very often. Allocating white seemed to help that a lot.
Locking just to check the color is not good though.


   --- 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