Tcl Source Code

Four tests raising errors in the HEAD
of the Thread package:

==== thread-19.10 thread::mutex - destroy locked exclusive mutex FAILED
==== Contents of test case:

    set emutex [thread::mutex create]
    thread::mutex lock $emutex
    set x [catch {thread::mutex destroy $emutex} msg]
    thread::mutex unlock $emutex
    thread::mutex destroy $emutex
    list $x $msg

---- Test generated error; Return code was: 1
---- Return code should have been one of: 0 2
---- errorInfo: no such mutex "mid6"
    while executing
"thread::mutex unlock $emutex"
    ("uplevel" body line 5)
    invoked from within
"uplevel 1 $script"
---- errorCode: NONE
==== thread-19.10 FAILED



==== thread-19.11 thread::mutex - destroy locked recursive mutex FAILED
==== Contents of test case:

    set rmutex [thread::mutex create -recursive]
    thread::mutex lock $rmutex
    set x [catch {thread::mutex destroy $rmutex} msg]
    thread::mutex unlock $rmutex
    thread::mutex destroy $rmutex
    list $x $msg

---- Test generated error; Return code was: 1
---- Return code should have been one of: 0 2
---- errorInfo: no such mutex "rid7"
    while executing
"thread::mutex unlock $rmutex"
    ("uplevel" body line 5)
    invoked from within
"uplevel 1 $script"
---- errorCode: NONE
==== thread-19.11 FAILED



==== thread-20.6 thread::mutex - destroy readlocked mutex FAILED
==== Contents of test case:

    set rwmutex [thread::rwmutex create]
    thread::rwmutex rlock $rwmutex
    set x [catch {thread::rwmutex destroy $rwmutex} msg]
    thread::rwmutex unlock $rwmutex
    thread::rwmutex destroy $rwmutex
    list $x $msg

---- Test generated error; Return code was: 1
---- Return code should have been one of: 0 2
---- errorInfo: no such mutex "wid10"
    while executing
"thread::rwmutex unlock $rwmutex"
    ("uplevel" body line 5)
    invoked from within
"uplevel 1 $script"
---- errorCode: NONE
==== thread-20.6 FAILED



==== thread-20.7 thread::mutex - destroy writelocked mutex FAILED
==== Contents of test case:

    set rwmutex [thread::rwmutex create]
    thread::rwmutex wlock $rwmutex
    set x [catch {thread::rwmutex destroy $rwmutex} msg]
    thread::rwmutex unlock $rwmutex
    thread::rwmutex destroy $rwmutex
    list $x $msg

---- Test generated error; Return code was: 1
---- Return code should have been one of: 0 2
---- errorInfo: no such mutex "wid11"
    while executing
"thread::rwmutex unlock $rwmutex"
    ("uplevel" body line 5)
    invoked from within
"uplevel 1 $script"
---- errorCode: NONE
==== thread-20.7 FAILED

Committed after review by mistachkin.

File Added - 325597: thr1.patch

OK I reordered things a bit in RemoveMutex (and similarly for cond vars). Test suite OK now (with other hanging test fix).
I didn't touch the test themselves, because the style was not the culprit, as it turns out. The half-destruction was the root cause of the unclear result...

I don't know any more. Its been a long time I looked
at that code. I will look into it...  Lately I am just 
swamped with the "regular" work so I simply cannot
get any spare time for other activities... 

Cheers
Zoran

Looking at the code of RemoveMutex, it is obvious that RemoveAnyItem is called *before* SpMutexFinalize, which is responsible for checking locked status. Hence the behavior: the Tcl-related data structures (hash entry for the lock) are removed despite the abortion of the destroy operation. Now why are things done in this bizarre order ?

More precisely, if the intent of the test is to verify that a held lock cannot be destroyed, then the style is obscure. Just adding an "if {$x} {...}" around the two cleanup lines would restore a clearer failure report.

Sorry, I don't understand: in all 4 cases the destroy seems to work, and the subsequent unlock attempt fails because the lock no longer exists. What am I missing ?

Sorry for delay. I will look into that over the weekend.
Was extremely busy last several months...

Cheers
Zoran

Any chance someone can look into
these?  

I'd like to consider Thread for
bundling with Tcl 8.6, but failures
like this make me think it's not ready.