On Thu, Mar 24, 2016 at 2:07 AM, Ben Coman btc@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 testWaitingProcessReceivingLockTerminatedBeforeResuming.
- low priority process B waits on lock because it is owned by another process A
- 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, commits@source.squeak.org 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 eliot.miranda@gmail.com 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