[gclist] A problem with the Baker treadmill.
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,
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 email@example.com firstname.lastname@example.org
If you have a PowerMac check out SuperCollider, a real time synth program: