From: Gábor Melis <melisgl@us...> - 2009-01-11 15:56:13
Update of /cvsroot/sbcl/sbcl/src/code
In directory fdv4jf1.ch3.sourceforge.com:/tmp/cvs-serv23922/src/code
126.96.36.199: undo parts of 188.8.131.52
No need for memory barriers when unlocking a spinlock on x86/x86-64.
The ordering rules and the cache coherency mechanism together
guarantee this. However, the compiler must be prevented from
reordering instructions with the unlock (at least in one direction).
This is now done in the runtime, but not in Lisp as the Lisp compiler
does no reordering.
RCS file: /cvsroot/sbcl/sbcl/src/code/target-thread.lisp,v
retrieving revision 1.99
retrieving revision 1.100
diff -u -d -r1.99 -r1.100
--- target-thread.lisp 9 Jan 2009 16:45:17 -0000 1.99
+++ target-thread.lisp 11 Jan 2009 15:56:03 -0000 1.100
@@ -224,15 +224,18 @@
(defun release-spinlock (spinlock)
(declare (optimize (speed 3) (safety 0)))
- ;; Simply setting SPINLOCK-VALUE to NIL is not enough as it does not
- ;; propagate to other processors, plus without a memory barrier the
- ;; CPU might reorder instructions allowing code from the critical
- ;; section to leak out. Use COMPARE-AND-SWAP for the memory barrier
- ;; effect and do some sanity checking while we are at it.
- (unless (eq *current-thread*
- (sb!ext:compare-and-swap (spinlock-value spinlock)
- *current-thread* nil))
- (error "Only the owner can release the spinlock ~S." spinlock)))
+ ;; On x86 and x86-64 we can get away with no memory barriers, (see
+ ;; Linux kernel mailing list "spin_unlock optimization(i386)"
+ ;; thread, summary at
+ ;; http://kt.iserv.nl/kernel-traffic/kt19991220_47.html#1.
+ ;; If the compiler may reorder this with other instructions, insert
+ ;; compiler barrier here.
+ ;; FIXME: this does not work on SMP Pentium Pro and OOSTORE systems,
+ ;; neither on most non-x86 architectures (but we don't have threads
+ ;; on those).
+ (setf (spinlock-value spinlock) nil))