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> 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 ;)



Best,

Jaromir



--

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,
Christoph

---
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/cd9c4e55/attachment.html>