You might like to take a look at the reference counting rules used by COM
(yeah, boo hiss, I know). That specifies who should increment/decrement the
count for various situations.
Right - the more I've discussed this and poked at it, the more I've
realized that reference counting and not mutex behavior is the way to
describe the problem.
Also, what is the purpose of using atomic_compare_swap like that? Normally
with reference counting, the garbage collection is done when the reference
count reaches zero after decrementing it. At that point, nothing else should
be referencing it, so there seems to be little point in doing
Deferred deletion...we defer actually nuking the object until
later...when new objects are loaded, they check the cache of objects and
possibly reincarnate one...this avoids delete/recreate thrash.
A lock is needed on the pool of garbage-colectable objects, to assure
that the reincarnation code and garbage collection code don't kill each
Do not post admin requests to the list. They will be ignored.
PerfOptimization-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden