Mailing Lists: Apple Mailing Lists
 Image of Mac OS face in stamp
Re: Atomic ops as protection
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Atomic ops as protection

Hi Martin,

Martin Simmons wrote:

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

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

cheers
ben
_______________________________________________
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






References: 


 >Atomic ops as protection (From: Ben Supnik <email@hidden>)


 >Re: Atomic ops as protection (From: John Stiles <email@hidden>)


 >Re: Atomic ops as protection (From: Ben Supnik <email@hidden>)


 >Re: Atomic ops as protection (From: Martin Simmons <email@hidden>)























Visit the Apple Store online or at retail locations.

1-800-MY-APPLE


Contact Apple | Terms of Use | Privacy Policy


Copyright © 2011 Apple Inc. All rights reserved.