Re: [boost] Solaris versions of sp_counted_base and atomic_count by Michael van der Westhuizen

From: Michael van der Westhuizen (r1mikey_at_[hidden])
Date: 2006-07-03 11:20:32

On 7/3/06, Peter Dimov <pdimov_at_[hidden]> 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.s

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