re: > U trunk/include/asterisk/lock.h > > ---------------------------------------------------------------------- > -- > r91114 | russell | 2007-12-04 19:56:46 -0600 (Tue, 04 Dec 2007) | > 19 lines
Please accept my apologies if this is not the correct venue, but it seems the comment area on the listed bugs are closed. 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? 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? Thanks! Tod Fitch _______________________________________________ --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
