killing lutexes, adding timeouts

  * Remove all lutex-specific code from the system.
    ** Use SB-FUTEX for futex-capable platforms, and plain SB-THREAD
       otherwise.
    ** Make non-futex mutexes unfair spinlocks for now, using WAIT-FOR to
       provide timeouts and backoff.
    ** Build non-futex condition variables on top of a queue and WAIT-FOR.

    Performance implications: SB-FUTEX builds should perform pretty much the
    same, or improve a bit. Threaded non-futex builds are affected as follows:

      1. Threads idling on semaphores or condition variables aren't quite as
         cheap. Just how costly depends on the OS. On Darwin 1000 idle threads
         can chew up a bit over 50% CPU. I will try to address this later.

      2. Contested locking around operations that take considerably longer
         than a single timeslice suffers mild degradation.

      3. Contested locking around operations that don't take long is an order
         of magnitude performant.

      4. Highly active semaphores perform much better. (Follows from #3.)

  * GRAB-MUTEX gets timeout support on all platforms.

  * CONDITION-WAIT gets timeout support.

  * Disable a bunch of prone-to-hang thread tests on Darwin.  (All of them
    were already prone to hang prior to this commit.)

  * Enable a bunch tests that now /pass/ on Darwin. \o/ This doesn't mean that
    the threaded Darwin is fully expected to pass all tests yet, but let's say
    it's more likely to do so.

    ...but still not robust enough to enable threads on Darwin by default.

  * GET-MUTEX/GRAB-MUTEX get refactored into two main parts: %TRY-MUTEX and
    %WAIT-ON-MUTEX, which are also used directly from CONDITION-WAIT where
    appropriate.

1 files changed, 3 insertions, 6 deletions

diff --git a/base-target-features.lisp-expr b/base-target-features.lisp-expr
index 019b37efc..8237b15ef 100644
--- a/base-target-features.lisp-expr
+++ b/base-target-features.lisp-expr
@@ -221,15 +221,12 @@
  ;; x86oid Darwin, FreeBSD, and Solaris.
  ; :sb-thread
 
- ;; lutex support
+ ;; futex support
  ;;
  ;; While on linux we are able to use futexes for our locking
- ;; primitive, on other platforms we don't have this luxury. NJF's
- ;; lutexes present a locking API similar to the futex-based API that
- ;; allows for sb-thread support on x86 OS X, Solaris and
- ;; FreeBSD.
+ ;; primitive, on other platforms we don't have this luxury.
  ;;
- ; :sb-lutex
+ ; :sb-futex
 
  ;; On some operating systems the FS segment register (used for SBCL's
  ;; thread local storage) is not reliably preserved in signal