> ;;; The mere existence of threads waiting on conditions appears to
> ;;; slow down other code. This program demonstrates the problem.
This seems to be the O(threads) GC behaviour reported earlier by David
Lichteblau. I had a quick look at this, and the likely bottleneck is a
spinlock in sig_stop_for_gc_handler, which accounts for 97% of the
time spent in the sbcl runtime when running your test:
4 1.0e-03 : 8052991: xor %eax,%eax
: 8052993: lock cmpxchg %edx,0x8064a44
21723 5.4193 : 805299b: test %eax,%eax
366498 91.4309 : 805299d: jne 8052991 <sig_stop_for_gc_handler+0xa1>
Perhaps when gc_stop_the_world sends a SIG_STOP_FOR_GC signal to a
thread the kernel immediately schedules the thread, which spins since
gc_stop_the_world still holds the lock?