Hi Eliot, Nicolas, all,

I've been circling around a question how to terminate, i.e. unwind a process sitting at a condition variable inside an unwind block:

The old suspend primitive 88 unblocks the process and the unwind can proceed. The new suspend primitive 568/578 on the other hand backs it up before the wait send which means the unwind in such case won't proceed far - it will get sat back to the wait. It looks like for termination/unwind purposes it's more convenient to use the old prim 88 (called from e.g. suspendAndUnblock method Nicolas suggested). Just making sure I haven't overlooked anything.

Now, if the process gets unblocked from the condition variable, the unwind would proceed *as if* the process got a signal on the condition variable. I've sent a question to the dev-list about such unblocking in case of a mutex. It looks suspicious that a process continues into the critical block without acquiring the ownership and even niling the existing ownership. I'm not sure I understand the Mutex correctly though. Here's the test:

testMutexBlockedInCritical          "self run: #testMutexBlockedInCritical"

                | lock sock proc wait |
                lock := Mutex new.
                sock := Semaphore new.
                proc := [lock critical: [sock wait]] fork.
                wait := [[] ensure: [lock critical: []]] fork.  "<---- important"
                Processor yield.
                self assert: proc suspendingList == sock.
                self assert: wait suspendingList == lock.
                self deny: lock isEmpty.
                self assert: lock isOwned.
                wait terminate.
                Processor yield.
                self assert: wait isTerminated.
                self assert: proc suspendingList == sock.
                self assert: wait suspendingList == nil.
                self assert: lock isEmpty.
                self deny: lock isOwned            "<---- is this right???"


Similarly, this modified Semaphore test fails too:

testSemaInCriticalWait2                "self run: #testSemaInCriticalWait"
                "This tests whether a semaphore that has entered the wait in Semaphore>>critical:
                leaves it without signaling the associated semaphore."
                | s p |
                s := Semaphore new.
                p := [[] ensure: [s critical:[]]] fork.   "<---- important"
                Processor yield.
                self assert:(p suspendingList == s).
                p terminate.
                self assert: 0 equals: s excessSignals        "<---- s will have 1 excess signal!!!"


Is this something to worry about? How should a process unblocked from a condition variable continue, actually? Or maybe just in case of critical sections the behavior could be restricted, e.g. to avoid evaluating the critical section?

Thanks for any comments,

Jaromir


--

Jaromír Matas

mail at jaromir.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220528/1d77e0e6/attachment.html>