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 OwnedLock.zip (21K) Download Attachment |
btw, I am away over Easter and may be slow to respond. cheers -ben On Thu, Mar 24, 2016 at 2:07 AM, Ben Coman <[hidden email]> 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 > 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 |
In reply to this post by Ben Coman
On Thu, Mar 24, 2016 at 2:07 AM, Ben Coman <[hidden email]> 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 > 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? 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? cheers -ben |
In reply to this post by Ben Coman
On Thu, Mar 24, 2016 at 2:07 AM, Ben Coman <[hidden email]> 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 > 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 Per recent thread... On Tue, Apr 12, 2016 at 2:02 AM, <[hidden email]> wrote: > > ClementBera uploaded a new version of VMMaker to project VM Maker: > http://source.squeak.org/VMMaker/VMMaker.oscog-cb.1795.mcz > > ==================== Summary ==================== > > Name: VMMaker.oscog-cb.1795 > Author: cb > Time: 11 April 2016, 11:01:37.99209 am > UUID: 7e723234-b8d0-46a7-8e2c-180da3482a3b > Ancestors: VMMaker.oscog-cb.1794 > > Fixed minor things to make slang compilation happy. > > =============== Diff against VMMaker.oscog-cb.1794 =============== > > (207 genPrimitiveFullClosureValue) "value[:value:value:value:] et al" > "(208 genPrimitiveFullClosureValueWithArgs)" "valueWithArguments:" > + (209 genPrimitiveFullClosureValue) "valueNoContextSwitch[:value:] et al" > - (209 genPrimitiveFullClosureValueNoContextSwitch) "valueNoContextSwitch[:value:] et al" > I notice 207-209 seem to be have been grabbed already. So I'll move the OwnedLock to use 150-152 per... On Tue, Feb 16, 2016 at 2:42 AM, Eliot Miranda <[hidden email]> wrote: > Hi Both, > > apologies for not responding sooner. I have been trying to release new > VMs (done, announcement soon). So use either 207,208 & > 209, or 150, 151 and 152. Let me have the code and I can integrate it. cheers -ben |
Free forum by Nabble | Edit this page |