[Vm-dev] Re: OwnedLock primitives request for review

[Ben Coman]

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
> 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,  <commits at 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 at 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