Hi Jaromir,

On Mon, Dec 27, 2021 at 2:52 AM <mail at jaromir.net> wrote:

> Hi all,
>
> What is the desirable semantics of resuming a previously suspended process?
>

That a process continue exactly as it had if it had not been suspended in
the first place.  In this regard our suspend is hopelessly broken for
processes that are waiting on condition variables. See below.


>
> #resume's comment says: "Allow the process that the receiver represents to
> continue. Put the receiver in *line to become the activeProcess*."
>
> The side-effect of this is that a terminating process can get resumed
> (unless suspendedContext is set to nil - see test KernelTests-jar.417 /
> Inbox - which has the unfortunate side-effect of #isTerminated answer true
> during termination).
>

But a process that is terminating should not be resumable.  This should be
a non-issue.  If a process is terminating itself then it is the active
process, it has nil as its suspendedContext, and Processor
activeProcess resume always produces an error.. Any process that is not
terminating itself can be made to fail by having the machinery set the
suspendedContext to nil.


> A similar side-effect: a process originally waiting on a semaphore and
> then suspended can be resumed into the runnable state and get scheduled,
> effectively escaping the semaphore wait.
>

Right,  This is the bug.  So for example
    | s p |
    s *:=* Semaphore new.
    p *:=* [s wait] newProcess.
    p resume.
    Processor yield.
    { p. p suspend }

answers an Array of process p that is past the wait, and the semaphore, s.
And

    | s p |
    s *:=* Semaphore new.
    p *:=* [s wait] newProcess.
    p resume.
    Processor yield.
    p suspend; resume.
    Processor yield.
    p isTerminated

answers true, whereas in both cases the process should remain waiting on
the semaphore.

>
> Is this an expected behavior or a bug?
>

IMO it is a dreadful bug.

> If a bug, should a suspended process somehow remember its previous state
> and/or queue and return to the same one if resumed?
>

IMO the primitive should back up the process to the
wait/primitiveEnterCriticalSection. This is trivial to implement in the
image, but is potentially non-atomic.  It is perhaps tricky to implement in
the VM, but will be atomic.

Sorry if I'm missing something :)
>

You're not missing anything :-)  Here's another example that answers two
processes which should both block but if resumed both make progress.

    | s p1 p2 m |
    s *:=* Semaphore new.
    m *:=* Mutex new.
    p1 *:=* [m critical: [s wait]] newProcess.
    p1 resume.
    p2 *:=* [m critical: [s wait]] newProcess.
    p2 resume.
    Processor yield.
    { p1. p1 suspend. p2. p2 suspend }

p1 enters the mutex's critical section, becoming the mutex's owner. p2 then
blocks attempting to enter m's critical section.  Let's resume these two,
and examine the semaphore and mutex:

    | s p1 p2 m |
    s *:=* Semaphore new.
    m *:=* Mutex new.
    p1 *:=* [m critical: [s wait]] newProcess.
    p1 resume.
    p2 *:=* [m critical: [s wait]] newProcess.
    p2 resume.
    Processor yield.
    { p1. p1 suspend. p2. p2 suspend }.
    p1 resume. p2 resume.
    Processor yield.
    { s. m. p1. p1 isTerminated. p2. p2 isTerminated }

In this case the end result for p2 is accidentally correct. It ends up
waiting on s within m's critical section. But p1 ends up terminated.  IMO
the correct result is that p1 remains waiting on s, and is still the owner
of m, and p2 remains blocked trying to take ownership of m.


>
> Best,
> ~~~
> ^[^    Jaromir
>
> Sent from Squeak Inbox Talk
>

_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211227/8719df13/attachment.html>