[squeak-dev] (no subject)

Jaromir Matas mail at jaromir.net
Sat May 28 19:57:56 UTC 2022

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,



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>

More information about the Squeak-dev mailing list