Process>>resume seems to cancel Semaphore>>wait, violating process synchronization guarantees

[martinmcclure]

Bug description
A Process performing a wait on a Semaphore with no excess signals should wait until that semaphore is signaled by some other Process, or until the waiting Process is terminated.
Instead, it looks like suspending and resuming the Process lets it "get out of jail free" and proceed past the wait it's in.
This is a Major violation of inter-process synchronization safety.

To Reproduce
Time millisecondsToRun: [
| proc sema1 sema2 |
sema1 := Semaphore new.
sema2 := Semaphore new.
proc := [
sema2 wait.
sema1 signal ] newProcess.
proc priority: Processor activeProcess priority - 1.
proc resume.
1 seconds wait.
proc suspend.
proc resume.
sema1 wait ]

Expected behavior
Hangs forever.

Actual behavior
Answers a number of milliseconds slightly over 1000.

Version information:

• OS: Linux
• Version: Gentoo stable
• Pharo Version: 9, build 1573

Expected development cost
Unknown. Much of the behavior is in primitives, so it could well be a VM issue.

[guillep]

Yes, I realized this some time ago too.

I wonder if we cannot just do it on the library side. Making the primitive resume into a method primitiveResume and then resume check before if it can resume. Doing it on the library side gives the opportunity of using some polymorphism on the process list ;)

[martinmcclure]

I haven't looked at the code in detail (and the VM code not at all) but am generally in favor of moving functionality into the image, and having only the minimum in the VM for necessary safety/critical sections.