[squeak-dev] New #suspend semantics

Jaromir Matas mail at jaromir.net
Thu Jun 16 14:08:45 UTC 2022

Hi Christoph,

Precisely; I like to use this example instead:

                p := [Semaphore new wait] fork.
                Processor yield.
                p suspend.
                p resume.
                Processor yield.
                {p isTerminated. p isBlocked}    "should answer #(false true)"

For some reason the example with Process forBlock: produces ‘Error: resume fails’ in 5.3. If you make it a test, that would be great; I’ve only added testRevisedSuspendExpectations but it is a good idea to test suspend+resume behavior as well.

> Revises #suspend to remember any semaphore or monitor that the receiver has been waiting for and restore the waiting state in #resume (the old behavior is available via #suspendAndUnblock).

Apologies for nitpicking: “remember” is not exactly what really happens, #suspend ‘simply’ returns process’s pc one instruction (i.e. the send that invoked the wait) back; so the next resume (which may never happen if you e.g. terminate) just executes the send again.

Eliot’s comment in #suspend expresses this nicely; maybe take it from there…

[if a process] was on some condition variable (Semaphore, Mutex) [then] back up its pc to the send that invoked the wait state the process entered.  Hence when the process resumes it will reenter the wait state.

I’ve read somewhere ‘official’ a short and exact description what suspend is supposed to do (not ANSI, somewhere else but can’t remember where) and this Eliot’s implementation does exactly that.

From: Thiede, Christoph<mailto:Christoph.Thiede at student.hpi.uni-potsdam.de>
Sent: Thursday, June 16, 2022 15:23
To: The general-purpose Squeak developers list<mailto:squeak-dev at lists.squeakfoundation.org>
Subject: Re: [squeak-dev] New #suspend semantics

Hi Jaromir,

thanks a lot for the summary!

Translating this to code for my own understanding:

p := Process forBlock: [Semaphore new wait].
p resume.
Processor yield.
p suspend.
p resume.
Processor yield.
{p isBlocked. p isTerminated}

has answered #(false true) in the past;

and now answers #(true false).

> Alas, I don't seem to be able to squeeze it into one sentence or even less ;)

Hm, I will try this:

Revises #suspend to remember any semaphore or monitor that the receiver has been waiting for and restore the waiting state in #resume (the old behavior is available via #suspendAndUnblock).

My question is answered then. :-)


Please apologize that I did not read the entire linked thread. We tend to write so much that the pure reading time for this thread (let alone any comprehension) would be close to 20 minutes. =D

One last quick question: Will there be tests for #suspendAndUnblock? Maybe something like my above example?


Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Jaromir Matas <mail at jaromir.net>
Gesendet: Montag, 13. Juni 2022 08:45 Uhr
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] New #suspend semantics

Hi Christoph,

The difference between the new #suspend using suspend primitive 578 and the previous one using primitive 88 is this:

Previously, if you suspended a process waiting on a semaphore or mutex the process was removed from the semaphore or mutex; subsequent #resume would let the process continue as if the process had never been waiting.

The new suspend with primitive 578 not only removes the process from the semaphore or mutex but backs it up one instruction, i.e. before the wait send, and thus a subsequent #resume will allow the process go back to the wait on the semaphore or mutex, i.e. to the same state as before the suspension.

One of the adverse effects of the previous behavior was #critical sections could have been entered multiple times regardless of the ownership of the condition variable.

The previous behavior have been used (or misused) to cheaply escape a condition variable; for backward compatibility the old behavior has been preserved in #suspendAndUnblock.

Here's more: http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-December/217831.html

Alas, I don't seem to be able to squeeze it into one sentence or even less ;)




Jaromír Matas

mail at jaromir.net

From: christoph.thiede at student.hpi.uni-potsdam.de<mailto:christoph.thiede at student.hpi.uni-potsdam.de>
Sent: Sunday, June 12, 2022 21:45
To: squeak-dev at lists.squeakfoundation.org<mailto:squeak-dev at lists.squeakfoundation.org>
Subject: [squeak-dev] New #suspend semantics

Hi Jaromír,

as I'm currently updating the release notes, I'm trying to figure out what exactly are the visible effects of your changes to #suspend and #suspendAndUnblock from May 30.

There has been written so much about this on the list in the last months that it's hard to follow up. If you could just describe the changes very briefly, probably in one or a half sentence, that would be perfect. :D

Thanks in advance,

Sent from Squeak Inbox Talk<https://github.com/hpi-swa-lab/squeak-inbox-talk>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220616/9551061f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: C6E11A0D91624B92934B92D3F3A3CA3B.png
Type: image/png
Size: 144 bytes
Desc: C6E11A0D91624B92934B92D3F3A3CA3B.png
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220616/9551061f/attachment.png>

More information about the Squeak-dev mailing list