[asterisk-dev] Regarding the fix for bugs 11289 and 11176 on Mac OS X

[Russell Bryant]

Tod Fitch wrote:
> Please accept my apologies if this is not the correct venue, but it  
> seems the comment area on the listed bugs are closed.

This is the correct venue.  :)

> The fix check-in comment notes that the OSX version of OSAtomicAdd32 
> () and OSAtomicAdd64() return the value after the operation rather  
> than the expected previous value.
> 
> Reading the Apple man page on these, that is true. But  
> ast_atomic_dec_and_test() also use these same OS routines and were  
> not changed. Should they be updated too?

Nope, those are fine.  Those functions did expect the new value, because it's
checking to see if the value is now 0.

> Also, from reading the Apple man page it seems that for threaded  
> applications on a multi-processor computer, especially PPC  
> architectures, it seems that OSAtomicAdd32Barrier() and  
> OSAtomicAdd64Barrier() might be safer choices than the non-barrier  
> versions. See:
> 
> http://developer.apple.com/documentation/Darwin/Reference/ManPages/ 
> man3/OSAtomicAdd64.3.html
> 
> Are these concerns valid? If so should a new bug be opened or is the  
> general policy to reopen an old bug?

Well, it seems to me that if _all_ operations on the integer are using
OSAtomicAdd32(), which is the case where these are used in Asterisk, then the
Barrier version would not be necessary.  But, I'd like to hear any opinions from
those with more experience and knowledge than me at this low of a level.

-- 
Russell Bryant
Senior Software Engineer
Open Source Team Lead
Digium, Inc.