 |
lua-l archive |
|
|
||
|
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