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

If you always use the atomic ops when working with a variable, you should be able to assume non-wonky behavior—that's the point of using them. If they didn't sort out the ordering/coherency/cache issues for you, they wouldn't be very useful for threaded programming :)

Note the "always" above—all it takes is one non-atomic operation on a value and you are back in wonky-land :)


Ben Supnik wrote: 
Hi John,

Yes...well, some hand-waving makes that go away. :-)

I think the issue is: a race condition between how we get our "obj" ptr and when we increment it's reference count.

To be truly safe, the routine that gets us an obj ptr needs to increment the reference count before it returns it to us....in other words:

- Some kind of "store-house" has the ptrs to the objects and has its reference count incremented.

- The store house increments the reference count by one and gives it back to us.

- We decrement it when we're done with it.

Thus the store house can decrement its own reference count and forget the object after it's given to us.

Is this the only race condition? My concerns were more low-level, e.g. do atomic ops really guarantee that (for this one integer variable) we don't have to worry about caching and memory-ordering rules, etc.

cheers
Ben

John Stiles wrote:
What if your atomic_compare_swap occurs immediately before the atomic_inc?
Thread 2 would be nuking the object while thread 1 is incrementing the refcount.
I might be missing something but I don't see what prevents this from occurring.


Ben Supnik wrote: 
Hi Y'all,

I'm looking at using an atomic reference count as sort of protection for an object.

A thread using an object wants to be totally sure that a garbage collector isn't going to kill it off, so it bumps the reference count up while using it. Something like this...

struct obj {
  int  ref_count;
  ...
}

thread 1:

atomic_inc(&obj->ref_count);
do stuff to obj
atomic_dec(&obj->ref_count);

thread 2:

if(atomic_compare_swap(obj->ref_count, 0, -1))
   nuke the object

Do I have this right? If I was using a critical section I'd trust that the nuke-the-object code can't run at the same time as the do-stuff-to-obj code.

Is treating ref_count atomically enough to ensure that I won't get a nuke while processing the object?

I am assuming of course that no third thread randomly decrements the reference count without incrementing (which would "unlock" the object behind thread 1's back).

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























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.