I have the OwnedLock primitives and image side code suggested by Dennis for Pharo ready for review... (207 #primitiveOwnedLockRelease) (208 primitiveOwnedLockTryAcquire) (209 primitiveOwnedLockWaitAcquire)
Dennis identified an interesting corner case codified in testWaitingProcessReceivingLockTerminatedBeforeResuming.
1) low priority process B waits on lock because it is owned by another process A 2) process A release lock but process B not resumed since higher priority process C is running 3) process C terminates process B 4) process B should (but does not) release acquired lock during termination.
This is because B is given the lock by A's call to primitivexxRelease, and the ensure in #critical doesn't wrap B's call to primitivexxWaitAcquire. However wrapping an ensure around the whole #critical means if the process is terminated while waiting, you need to be careful not to releasing someone else's lock. All a little bit messy.
Now I read recently something about primitive handling of forwarders being done by side-effect-free failing of primitives and retying, and I wonder if the same might be feasible here. Rather than A's call to primitivexxRelease setting B as the lock owner, it just sets the owner to nil, and when B is woken up, it retries primitivexxWaitAcquire.
How does that sound?
cheers -ben