From: Nikodemus S. <nik...@ra...> - 2011-05-11 16:55:45
|
I just committed deadlock detection code for spinlocks and mutexes into CVS. Please let me know if you see slowdowns in applications due to this: currently deadlocks are checked always on contested locks, but I can make it optional if there are performance issues. Cheers, -- Nikodemus |
From: Jim W. <jw...@dr...> - 2011-05-11 18:20:56
|
Nikodemus Siivola <nik...@ra...> writes: > I just committed deadlock detection code for spinlocks and mutexes into CVS. > > Please let me know if you see slowdowns in applications due to this: > currently deadlocks are checked always on contested locks, but I can > make it optional if there are performance issues. FWIW, the new test DEADLOCK-DETECTION.3 hangs indefinitely on Solaris/x86 (.1 and .2 run successfully). I'll test later today or early tomorrow on MacOS, to see if this affects other lutex builds. I interrupted the run manually after some time, yielding the following stack trace (I've trimmed to just the bits from when the test is begun until the SIGINT begins to be handled): 14: ((FLET SB-UNIX::RUN-HANDLER))[:EXTERNAL] 15: ("foreign function: call_into_lisp") 16: ("foreign function: funcall3") 17: ("foreign function: interrupt_handle_now") 18: ("foreign function: maybe_defer_handler") 19: ("foreign function: __moddi3") 20: ("foreign function: _sema_post") 21: ("foreign function: _sema_post") 22: ("bogus stack frame") 23: ("foreign function: _thr_schedctl") 24: ("foreign function: mutex_lock") 25: ("foreign function: lutex_lock") 26: (GET-MUTEX #<unavailable argument> #<unavailable argument> #<unavailable argument> #<unavailable argument>) 27: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]301)) 28: (SB-THREAD::CALL-WITH-MUTEX #<FUNCTION (FLET SB-THREAD::WITH-MUTEX-THUNK) {4AACFDCD}> #<MUTEX "M1" owner: #1=#<THREAD "T1" #2=waiting for: #<MUTEX "M2" owner: #> {4AADA649}>> #<THREAD "initial thread" waiting for: #<MUTEX "M1" owner: #1=#<THREAD "T1" #2=waiting for: # {4AADA649}>> timeout: 0.1 {49A8B1A9}> T) 29: ((FLET SB-THREAD::WITH-MUTEX-THUNK)) 30: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]301)) 31: (SB-THREAD::CALL-WITH-MUTEX #<CLOSURE (FLET SB-THREAD::WITH-MUTEX-THUNK) {FE9FF715}> #<MUTEX "M2" owner: #1=#<THREAD "initial thread" #2=waiting for: #<MUTEX "M1" owner: #> timeout: 0.1 {49A8B1A9}>> #<THREAD "initial thread" waiting for: #<MUTEX "M1" owner: #1=#<THREAD "T1" #2=waiting for: # {4AADA649}>> timeout: 0.1 {49A8B1A9}> T) 32: (#:EVAL-THUNK) 33: (SB-INT:SIMPLE-EVAL-IN-LEXENV (WITH-TEST (:NAME DEADLOCK-DETECTION.3) (LET* ((M1 (MAKE-MUTEX :NAME "M1")) (M2 (MAKE-MUTEX :NAME "M2")) (S1 (MAKE-SEMAPHORE :NAME "S1")) (S2 (MAKE-SEMAPHORE :NAME "S2")) (T1 (MAKE-THREAD (LAMBDA () (WITH-MUTEX (M1) (SIGNAL-SEMAPHORE S1) (WAIT-ON-SEMAPHORE S2) (WITH-MUTEX (M2) :OK))) :NAME "T1"))) (ASSERT (EQ :DEADLINE (HANDLER-CASE (WITH-MUTEX (M2) (SIGNAL-SEMAPHORE S2) (WAIT-ON-SEMAPHORE S1) (SLEEP 1) (SB-SYS:WITH-DEADLINE (:SECONDS 0.1) (WITH-MUTEX (M1) :OK))) (SB-SYS:DEADLINE-TIMEOUT NIL :DEADLINE)))) (ASSERT (EQ :OK (JOIN-THREAD T1))))) #<NULL-LEXENV>) 34: (SB-EXT:EVAL-TLF (WITH-TEST (:NAME DEADLOCK-DETECTION.3) (LET* ((M1 (MAKE-MUTEX :NAME "M1")) (M2 (MAKE-MUTEX :NAME "M2")) (S1 (MAKE-SEMAPHORE :NAME "S1")) (S2 (MAKE-SEMAPHORE :NAME "S2")) (T1 (MAKE-THREAD (LAMBDA () (WITH-MUTEX (M1) (SIGNAL-SEMAPHORE S1) (WAIT-ON-SEMAPHORE S2) (WITH-MUTEX (M2) :OK))) :NAME "T1"))) (ASSERT (EQ :DEADLINE (HANDLER-CASE (WITH-MUTEX (M2) (SIGNAL-SEMAPHORE S2) (WAIT-ON-SEMAPHORE S1) (SLEEP 1) (SB-SYS:WITH-DEADLINE (:SECONDS 0.1) (WITH-MUTEX (M1) :OK))) (SB-SYS:DEADLINE-TIMEOUT NIL :DEADLINE)))) (ASSERT (EQ :OK (JOIN-THREAD T1))))) 21 #<NULL-LEXENV>) -- Jim Wise jw...@dr... |
From: Nikodemus S. <nik...@ra...> - 2011-05-11 18:24:58
|
On 11 May 2011 21:20, Jim Wise <jw...@dr...> wrote: > FWIW, the new test DEADLOCK-DETECTION.3 hangs indefinitely on Solaris/x86 > (.1 and .2 run successfully). I'll test later today or early tomorrow > on MacOS, to see if this affects other lutex builds. I'm a moron. No mutex deadlines lutex builds. I'll check in a fix ... tomorrow, I think. This day is running late already. (Just realized there's a related bug in the deadlock detection code as well when considering deadlines.) Cheers, -- Nikodemus |
From: Nikodemus S. <nik...@ra...> - 2011-05-11 19:44:17
|
On 11 May 2011 21:24, Nikodemus Siivola <nik...@ra...> wrote: >> FWIW, the new test DEADLOCK-DETECTION.3 hangs indefinitely on >> Solaris/x86 > I'm a moron. No mutex deadlines lutex builds. I'll check in a fix ... Done. Hopefully Solaris is happy with 1.0.48.12... Cheers, -- nikodemus |
From: Jim W. <jw...@dr...> - 2011-05-11 20:37:39
|
Nikodemus Siivola <nik...@ra...> writes: > On 11 May 2011 21:24, Nikodemus Siivola <nik...@ra...> wrote: > >>> FWIW, the new test DEADLOCK-DETECTION.3 hangs indefinitely on >>> Solaris/x86 > >> I'm a moron. No mutex deadlines lutex builds. I'll check in a fix ... > > Done. Hopefully Solaris is happy with 1.0.48.12... Looks good. All of the new tests now pass, and the same set of old ones fail as before these changes. Thanks! -- Jim Wise jw...@dr... |