lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Dave Dodge wrote:
On Tue, Oct 10, 2006 at 02:07:51PM +0200, Mike Pall wrote:
Please. If updates to a pointer sized quantity (32 bit on 32 bit
systems, 64 bit on 64 bit systems) are non-atomic, fire the CPU
designer team. AFAIK none of the 64 bit multi-core machines on
the market do this.

The ARMv6 SMP code in the Linux kernel uses a small block of assembly
code, including a loop, to perform an atomic store.  It has a dire
warning that a normal store is not sufficient.

Sparc32 (which is certainly still out there in SMP configurations)
requires spinlocks and other mechanisms to get 32-bit atomic
operations.  It was famously limited to only 24 bits of atomicity in
the Linux kernel until relatively recently.

I'm sure there's more...

Oh yes, there are many examples, especially in the embedded
microcontroller world. In many cases, the internal bus width
is 16 bits, but the address space extends to 24 or 32 bits,
which requires pointers larger than the 16 bit limit. The
Motorola (now Freescale) HC16 and HC12 processors come to mind.

For those processors, storing any 32 bit value atomically
requires at least two instructions, and possibly 3 or more
if auto increment is not supported on the processor.

In these cases, the atomic store can be handled in a couple
of ways. One is to completely disable interrupts around the
store, and the other is to ensure that only one task can access
the storage location by using a resource lock.

Either way, it gets pretty expensive if you are doing a lot of
reading and writing of these kinds of values...

Ralph