[squeak-dev] New #suspend semantics

Marcel Taeumel marcel.taeumel at hpi.de
Tue Jun 21 10:28:58 UTC 2022


Thanks. Merged.
Am 20.06.2022 18:30:54 schrieb Jaromir Matas <mail at jaromir.net>:
Hi Marcel,
 
Two more tests to cover #suspendAndUnblock when used to unblock a process from a condition variable (by the “suspend; resume” trick) in KernelTests-jar.436.
 
+1 on Eliot’s chiseled #suspend description :)
 
From: Marcel Taeumel [mailto:marcel.taeumel at hpi.de]
Sent: Monday, June 20, 2022 10:16
To: squeak-dev [mailto:squeak-dev at lists.squeakfoundation.org]
Subject: Re: [squeak-dev] New #suspend semantics
 
+1 on
 
 "Revises suspend to ensure a process waiting on a semaphore or mutex, if suspended and then resumed, will continue to wait on the semaphore or mutex. Previously suspend would cause a process to no longer be waiting when resumed."
 
Best,
Marcel
Am 17.06.2022 21:54:40 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
 
 
On Fri, Jun 17, 2022 at 4:12 AM Jaromir Matas <mail at jaromir.net [mailto:mail at jaromir.net]> wrote:
Hi Christoph,
 
I understand now why you asked for ‘one sentence’ only to summarize #suspend changes to the release notes; here’s my suggestion:
 
Revises #suspend to stop the receiver waiting on a semaphore or mutex in such a way that sending it the message #resume will restore receiver's previous waiting state.
 
How about "Revises suspend to ensure a process waiting on a semaphore or mutex, if suspended and then resumed, will continue to wait on the semaphore or mutex. Previously suspend would cause a process to no longer be waiting when resumed."
It's two sentences but "to stop the receiver waiting" is potentially confusing.
 
 
 
From: Jaromir Matas [mailto:mail at jaromir.net]
Sent: Thursday, June 16, 2022 16:09
To: The general-purpose Squeak developers list [mailto:squeak-dev at lists.squeakfoundation.org]
Subject: Re: [squeak-dev] New #suspend semantics
 
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.
Thanks,
Jaromir
 
 
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?
 
Best,
Christoph
 
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org [mailto:squeak-dev-bounces at lists.squeakfoundation.org]> im Auftrag von Jaromir Matas <mail at jaromir.net [mailto: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 [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 ;)
 
Best,
Jaromir
 
--
Jaromír Matas
mail at jaromir.net [mailto: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,
Christoph

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

 
--
_,,,^..^,,,_
best, Eliot
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220621/861f55f8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: C6E11A0D91624B92934B92D3F3A3CA3B.png
Type: image/png
Size: 144 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220621/861f55f8/attachment.png>


More information about the Squeak-dev mailing list