[Sbcl-commits] CVS: sbcl/src/code alloc.lisp, 1.3, 1.4 gc.lisp, 1.80, 1.81 target-thread.lisp, 1.101, 1.102 unix.lisp, 1.95, 1.96

[Gabor M. <me...@us...>]

Update of /cvsroot/sbcl/sbcl/src/code
In directory fdv4jf1.ch3.sourceforge.com:/tmp/cvs-serv483/src/code

Modified Files:
	alloc.lisp gc.lisp target-thread.lisp unix.lisp 
Log Message:
1.0.25.14: comments


Index: alloc.lisp
===================================================================
RCS file: /cvsroot/sbcl/sbcl/src/code/alloc.lisp,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -d -r1.3 -r1.4
--- alloc.lisp	28 Jun 2007 14:24:48 -0000	1.3
+++ alloc.lisp	16 Feb 2009 21:25:44 -0000	1.4
@@ -33,6 +33,8 @@
                                  lowtag-mask))
                (new-pointer (+ *static-space-free-pointer* nwords))
                (new-free (* new-pointer n-word-bytes)))
+          ;; FIXME: don't signal while in WITHOUT-GCING, the handler
+          ;; risks deadlock with SIG_STOP_FOR_GC.
           (unless (> static-space-end new-free)
             (error 'simple-storage-condition
                    :format-control "Not enough memory left in static space to ~

Index: gc.lisp
===================================================================
RCS file: /cvsroot/sbcl/sbcl/src/code/gc.lisp,v
retrieving revision 1.80
retrieving revision 1.81
diff -u -d -r1.80 -r1.81
--- gc.lisp	12 Jan 2009 15:00:21 -0000	1.80
+++ gc.lisp	16 Feb 2009 21:25:44 -0000	1.81
@@ -177,8 +177,7 @@
 
 ;;; For GENCGC all generations < GEN will be GC'ed.
 
-(defvar *already-in-gc*
-  (sb!thread:make-mutex :name "GC lock") "ID of thread running SUB-GC")
+(defvar *already-in-gc* (sb!thread:make-mutex :name "GC lock"))
 
 ;;; A unique GC id. This is supplied for code that needs to detect
 ;;; whether a GC has happened since some earlier point in time. For

Index: target-thread.lisp
===================================================================
RCS file: /cvsroot/sbcl/sbcl/src/code/target-thread.lisp,v
retrieving revision 1.101
retrieving revision 1.102
diff -u -d -r1.101 -r1.102
--- target-thread.lisp	12 Jan 2009 15:00:21 -0000	1.101
+++ target-thread.lisp	16 Feb 2009 21:25:44 -0000	1.102
@@ -214,8 +214,9 @@
                    (thread-yield)
                    (return-from get-spinlock t))))
         (if (and (not *interrupts-enabled*) *allow-with-interrupts*)
-            ;; If interrupts are enabled, but we are allowed to enabled them,
-            ;; check for pending interrupts every once in a while.
+            ;; If interrupts are disabled, but we are allowed to
+            ;; enabled them, check for pending interrupts every once
+            ;; in a while.
             (loop
               (loop repeat 128 do (cas)) ; 128 is arbitrary here
               (sb!unix::%check-interrupts))
@@ -780,6 +781,9 @@
             ;; of Allegro's *cl-default-special-bindings*, as that is at
             ;; least accessible to users to secure their own libraries.
             ;;   --njf, 2006-07-15
+            ;;
+            ;; As it is, this lambda must not cons until we are ready
+            ;; to run GC. Be very careful.
             (let* ((*current-thread* thread)
                    (*restart-clusters* nil)
                    (*handler-clusters* (sb!kernel::initial-handler-clusters))

Index: unix.lisp
===================================================================
RCS file: /cvsroot/sbcl/sbcl/src/code/unix.lisp,v
retrieving revision 1.95
retrieving revision 1.96
diff -u -d -r1.95 -r1.96
--- unix.lisp	3 Jan 2009 16:17:48 -0000	1.95
+++ unix.lisp	16 Feb 2009 21:25:44 -0000	1.96
@@ -996,9 +996,21 @@
       (setf (values e-sec e-msec) (system-real-time-values)
             c-sec 0
             c-msec 0))
-    ;; If two threads call this at the same time, we're still safe, I believe,
-    ;; as long as NOW is updated before either of C-MSEC or C-SEC. Same applies
-    ;; to interrupts. --NS
+    ;; If two threads call this at the same time, we're still safe, I
+    ;; believe, as long as NOW is updated before either of C-MSEC or
+    ;; C-SEC. Same applies to interrupts. --NS
+    ;;
+    ;; I believe this is almost correct with x86/x86-64 cache
+    ;; coherency, but if the new value of C-SEC, C-MSEC can become
+    ;; visible to another CPU without NOW doing the same then it's
+    ;; unsafe. It's `almost' correct on x86 because writes by other
+    ;; processors may become visible in any order provided transitity
+    ;; holds. With at least three cpus, C-MSEC and C-SEC may be from
+    ;; different threads and an incorrect value may be returned.
+    ;; Considering that this failure is not detectable by the caller -
+    ;; it looks like time passes a bit slowly - and that it should be
+    ;; an extremely rare occurance I'm inclinded to leave it as it is.
+    ;; --MG
     (defun get-internal-real-time ()
       (multiple-value-bind (sec msec) (system-real-time-values)
         (unless (and (= msec c-msec) (= sec c-sec))