| commit | 78c7dbe937e6783e8da6f7a39c3eba87294d197c | |
| author | Gabor Melis <mega@hotpop.com> | |
| Mon, 16 Feb 2009 22:26:25 +0000 (16 22:26 +0000) | ||
| committer | Gabor Melis <mega@hotpop.com> | |
| Mon, 16 Feb 2009 22:26:25 +0000 (16 22:26 +0000) | ||
| tree | fb30e6377355ba47a28a718d0d4b63e2ff772f7f | treesnapshot (tar.gz zip) |
| parent | e5d96999ae4388181ddb0c113313f26afbe997e8 | commitdiff |
1.0.25.51: use WITH-RECURSIVE-SYSTEM-SPINLOCK
... instead of WITH-RECURSIVE-SPINLOCK because it's possible to
deadlock due to lock ordering with sufficiently unlucky interrupts as
demonstrated by test (:timer :parallel-unschedule) with low
probability.
This affects hash tables and some pcl locks.
Also, use WITH-RECURSIVE-MUTEX for packages.
Not a spinlock becuase it can be held for a long time and not a system
lock (i.e. with WITHOUT-INTERRUPTS) because conflicts are signalled
while holding the lock which I think this warrants a FIXME.
... instead of WITH-RECURSIVE-SPINLOCK because it's possible to
deadlock due to lock ordering with sufficiently unlucky interrupts as
demonstrated by test (:timer :parallel-unschedule) with low
probability.
This affects hash tables and some pcl locks.
Also, use WITH-RECURSIVE-MUTEX for packages.
Not a spinlock becuase it can be held for a long time and not a system
lock (i.e. with WITHOUT-INTERRUPTS) because conflicts are signalled
while holding the lock which I think this warrants a FIXME.