atomicity of unlocked reads

Frank Mayhar frank at exit.com
Wed Sep 17 22:57:58 PDT 2003


To throw another $.02 into the fray while I kill time between job inquiries
(sigh), Intel does have a few guaranteed-atomic operations.  From the IA-32
Software Developer's Manual Vol 3, "Guaranteed Atomic Operations," page
7-3:

    The Pentium 4, Intel Xeon, P6 family, Pentium, and Intel486 processors
    guarantee that the following basic memory operations will always be
    carried out atomically:
	o Reading or writing a byte.
	o Reading or writing a word aligned on a 16-bit boundary.
	o Reading or writing a doubleword aligned on a 32-bit boundary.

    The Pentium 4, Intel Xeon, and P6 family, and Pentium processors
    guarantee that the following additional memory operations will always
    be carried out atomically:
	o Reading or writing a quadword aligned on a 64-bit boundary.
	o 16-bit accesses to uncached memory locations that fit within a
	  32-bit data bus.

    The P6 family processors guarantee that the following additional
    memory operation will always be carried out atomically:
	o Unaligned 16-, 32-, and 64-bit accesses to cached memory that
	  fit within a 32-byte cache line.

(I wasn't consciously aware of these last two but they had occurred to me
when I wrote my previous email on this topic.  I'm certainly not
surprised; I would have been surprised if this _hadn't_ been the case.)

I don't have the docs for Alpha or PowerPC so I can't speak for those
architectures.  Bruce, you can certainly get away with doing your reads
unprotected, but I would still urge you to hide this inside an
"atomic_xxx_load" macro, just so it's caught properly by the ports
to the other architectures.

On the Intel architecture it's a cheap and easy optimization.  On another
architecture it may not be so cheap and easy, but at least it will _work_.
-- 
Frank Mayhar frank at exit.com	http://www.exit.com/
Exit Consulting                 http://www.gpsclock.com/
                                http://www.exit.com/blog/frank/


More information about the freebsd-smp mailing list