[Vm-dev] Re: OwnedLock primitives request for review
btc at openinworld.com
Thu Mar 24 16:57:32 UTC 2016
On Thu, Mar 24, 2016 at 2:07 AM, Ben Coman <btc at openinworld.com> wrote:
> 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
> 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
> 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?
I meant to ask, Eliot could you explain how primitive retry on
encountering a forwarder works, and/or point me to some code to study?
More information about the Vm-dev