On 7/3/06, Peter Dimov <pdimov@mmltd.net> wrote: [snip]
If you have any suggestions or comments, please let me know; in particular, if you have a better idea how to detect SunOS 5.10 or later, or if you know what memory synchronization guarantees the Solaris atomics are supposed to provide. :-)
Regarding memory synchronisation... The SPARC v9 architecture manual (http://developers.sun.com/solaris/articles/sparcv9.pdf) suggests that memory ordering is not a problem. Section 8.4.6 (Hardware Primitives for Mutual Exclusion) lists Compare and Swap (CAS) as being completely atomic. The following sentence from the manual suggests that (since we're not doing DMA or IO) we have a reliable solution: "In addition, the atomicity of hardware mutual-exclusion primitives is guaranteed only for processor memory references and not when the memory location is simultaneously being addressed by an I/O device such as a channel or DMA (impl. dep. #120)." The atomic_inc_32 and atomic_dec_32 functions are implemented in terms of "add32", which uses a CAS construct to perform the "add". I'd guess that these were implemented this way due to the atomic nature of CAS. All of that aside, the Solaris manual pages state that this interface is MT-safe, and the kernel versions of these functions are used in a similar way to what I've used in sp_counted_base_solaris.hpp, so I *hope* there are no memory ordering bugs lurking. The SPARC implementation of the atomic functions can be viewed in the OpenSolaris repository: http://cvs.opensolaris.org/source/xref/on/usr/src/common/atomic/sparc/atomic... I'm also going to post to the Solaris developers forums to see what feedback I can get on memory ordering issues, but questions like that have been pretty much ignored in the past. Michael