Boost logo

Boost :

From: Andy Glew (glew_at_[hidden])
Date: 1999-12-30 20:01:43


> > I don't think that's entirely correct. On many platforms, all integer
> > operations are atomic; the same can't be said of our smart pointers.
>
> And on many platforms they are not, so neither are safe.

I challenge you to list platforms where integer operations are
not read and write atomic. I make this challenge (1) because
I try to maintain a list of such atomicity and synchronization issues,
and (2) because I think it is entirely reasonable for most programmers
to assume atomicity for the aligned natural data types, 8, 16, 32, and possibly
64 bits, in ordinary cacheable memory.

Please note that I mean read and write atomicity,
not read-modify-write atomicity.
I.e.
        int i;
        i++
is unsafe on just about any system
(actually, on x86 and m68k, it is safe for non-multiprocessor
multithreading, but nowhere else)

I'll start a list both ways:

Intel x86:
    
    far pointers NOT atomic

    flat mode pointers (NT) are atomic.

    8,16,32 bit integers and FP are atomic.
    64 bit FP is atomic.
    64 bit MMX is atomic.

SUN SPARC:
MIPS
Alpha
PowerPC

    8, 16, 32, 64 aligned all atomic

-----

Basically, for most programming platforms atomicity assumptions
are perfectly reasonable.

I give myself wriggle room wrt embedded systems, but, again,
just about every embedded system using an 8080, Z80, or 8096,
or any of the RISC embedded chips, provides write atomicity
for 8 and 16 bit data types, and most do for 32 bit data types.

---
Where atomicity falls down is in dealing with I/O busses.
PCI is write atomic, as is EISA.
But some old ISA devices aren't.
Some VME devices aren't.
But, then, you can't assume anything with I/O.
    

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk