I notice the sys/atomic.h atomic_xxx interfaces are limited to things
that do read/modify/write (inc/dec/swap/etc). There is no atomic_set to
do a simple assignment.
In a couple headers defining wrappers around the atomic_xxx interfaces,
some define an atomic_set that does a simple assignment, with no added
protection.
Samples:
http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/drm/drm_atomic.h#57
http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/chxge/sge.h#53
Googling "atomic_set site:opensolaris.org" I found several discussions.
I see there is an issue with atomically setting a 64 bit value. There
are both 32 and 64 bit load/set instructions. If the compiler uses 2 32
bit operations on on 64 bit values (even though cache coherency is at a
64 bit level) an interrupt could occur between 2 32 bit operations,
causing half old/new.
Reference:
http://mail.opensolaris.org/pipermail/opensolaris-code/2007-May/005046.html
So on 64 bit values, some form of protection is required to be safe.
On 32 bit values, doing a simple a=b, it does not appear locking is
required.
Assuming my assessment above is correct, question is: is it considered
clean and proper to rely on this?
Just wondering if putback code reviews would consider this relying on
assumptions we shouldn't, or having unnecessary locking...
(I originally posed this question on the opensolaris discuss, but never
got an answer)
Thanks,
Joe
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
