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. _______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
