It isn't a simple as getting an old stale value. You can get a totally incorrect value. Example:
Let us assume a monotonically increased 64-bit values which at the start of this discussion is: 0x00000000ffffffff (32-bits 0, 32-bits 1). The 32-bit kernel goes to read the 64-bit value and does so by first loading the upper 32-bits (all 0s). At this point the thread is preempted or on an MP system another thread on another processor starts to do a 64-bit atomic increment. While that update is happening the first thread cannot read the lower 32-bits. The values after the atomic 64-bit update is now 0x0000000100000000 (lower 32-bits now all 0). Now that the update is complete the first thread reads the lower 32-bits. 0. So the 32-bit kernel has the potential for reading a 64-bits of 0 even though all 0 may NEVER have been an valid 64-bit value and all writes to that 64-bit location NEVER set it to all zero. In short, all those 64-bit locations that treat the value as being modified atomically can never rely on being read correctly, only updated correctly. Fortunately, on every modern 32-bit x86 processor, there is a compare and swap 8 byte instruction which can be used (with the lock prefix) to guarantee correct behavior, but first Solaris has to make sure that all 64-bit reads and writes use that feature and secondly, this isn't a general solution as other 32-bit processors may have no way to do a 64-bit atomic read/write without additional external locking. This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
