Although a SEMAPHORE's mutex is private to that SEMAPHORE, and the
mutex is released during the wait in WAIT-ON-SEMAPHORE, it's still
possible to starve in SIGNAL-SEMAPHORE while waiting to acquire the
mutex because a deadline handler around WAIT-ON-SEMAPHORE could be
running in the implicitly called CONDITION-WAIT which reacquires the
mutex.
Hence make sure that the call to GET-MUTEX in SIGNAL-SEMAPHORE is
interruptable.
* bug fix: a rare case of startup-time page table corruption.
* bug fix: a semaphore with multiple waiters and some of them unwinding due
to timeouts could be left in an inconsistent state.
+ * bug fix: fix typo in "Reporting Bugs" section of the manual (lp#520366)
changes in sbcl-1.0.37 relative to sbcl-1.0.36:
* enhancement: Backtrace from THROW to uncaught tag on x86oids now shows
(declare (type (integer 1) n))
;; Need to disable interrupts so that we don't lose a wakeup after
;; we have incremented the count.
- (with-system-mutex ((semaphore-mutex semaphore))
+ (with-system-mutex ((semaphore-mutex semaphore) :allow-with-interrupts t)
(let ((waitcount (semaphore-waitcount semaphore))
(count (incf (semaphore-%count semaphore) n)))
(when (plusp waitcount)
;;; checkins which aren't released. (And occasionally for internal
;;; versions, especially for internal versions off the main CVS
;;; branch, it gets hairier, e.g. "0.pre7.14.flaky4.13".)
-"1.0.37.12"
+"1.0.37.13"