[squeak-dev] Process #suspend / #resume semantics

mail at jaromir.net mail at jaromir.net
Wed Dec 29 13:22:06 UTC 2021

Hi Eliot, Craig and all,

I may be confused but let me ask:

(1) What is the desired semantics of suspending a process waiting on a condition variable; in particular: If you keep it waiting in the semaphore's queue what is supposed to happen when the semaphore is signaled?

	(i) the suspended process proceeds, i.e. as if not suspended 

	(ii) the suspended process keeps waiting until resumed and only then proceeds

	In case (i): The current suspend semantics will change; currently #suspend makes the process unrunnable until explicitely resumed. But if #suspend just fails and leaves the process waiting (blocked) in the semaphore's queue, the next signal will wake it and let it proceed.

	Question: current semantics suspends a process "unconditionally" allowing to pause the waiting process and ignore incoming semaphore signals - is this a desired and intentional behavior or just unintentional side-effect? 

	A semaphore wait on the other hand "suspends" a process "conditionally", i.e. until a signal becomes available. So option (i) would remove the "unconditional" suspension (of a waiting process) of a waiting process. I guess this is Craig's vote.

	In case (ii): What if another process enters the semaphore after the first gets suspended and a signal arrives: would it wait in line until the suspended process resumes and proceeds or would it "overtake" the waiting but suspended process and proceed using the available signal?

	Also, how would the blocked but suspended process be supposed to answer isBlocked and isSuspended? The current logic is based on testing myList and would probably have to change.

	In addition, what would resume do? Should it put the process back to proper blocked state to be able to consume a signal (i.e. retry wait)?

	It seems to me a process waiting on a semaphore could then exist in two possible states: normal blocked and suspended blocked :)

	I wouldn't mind either alternative but totally lack experience to judge it properly :)

	Or is there a third alternative (or interpretation of the second) that the suspended process is somehow "waiting" but outside the wainting queue?

(2) If I understand correctly, in both alternatives #suspend won't remove the process from the Semaphore's (or Mutex's) queue; meaning in both cases #terminate will have to remove the process from it's waiting queue (not only in the second alternative - right?).

My first idea was that #suspend would store the list the process was waiting on (in a new state 'oldList' possibly; after removing the process from it) and #resume would restore the process into its original queue but I indeed have no clue how complex this might be...

Probably a typo: did you mean 'ifFalse:' ?

    myList = myRunQueue ifFalse:
        [^self primitiveFailFor: PrimErrBadReceiver].



^[^    Jaromir

Sent from Squeak Inbox Talk

On 2021-12-28T23:49:47-08:00, craig at blackpagedigital.com wrote:

> Hi Eliot and all--
>  > There are two interpretations possible here. One is that suspend
>  > should fail if attempted on a process that is waiting on a condition
>  > variable. Another is that if the process is waiting on a condition
>  > variable, then suspend should back up the process so that on
>  > resumption the wait is retried... I'm interested in which of these
>  > people think we should implement.
>       I think it makes sense to regard a process waiting on a condition 
> variable as already suspended. This is in line with the traditional 
> semantics of Semaphore>>wait. So I would go for the first option, and 
> make suspend fail in this situation. An "already suspended" or 
> "operation isn't appropriate because the receiver is waiting" exception 
> might be useful and worthwhile.
>       Also, I don't like the notion of retrying a wait. That seems like 
> new territory for unfortunate edge cases.
>       happy end of the year!
>       Craig
> --
> Craig Latta  ::  research computer scientist
> Black Page Digital  ::  Berkeley, California
> 663137D7940BF5C0AFC :: 1349FB2ADA32C4D5314CE

More information about the Squeak-dev mailing list