[Vm-dev] OwnedLock primitives request for review
Ben Coman
btc at openinworld.com
Wed Mar 23 18:07:38 UTC 2016
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OwnedLock.zip
Type: application/zip
Size: 16089 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160324/4adb096b/OwnedLock.zip
More information about the Vm-dev
mailing list