[Vm-dev] New versions of primitives 186 and 187 with inverted logic?

[Ben Coman]

On Fri, Feb 5, 2016 at 12:16 AM, Denis Kudriashov <dionisiydk at gmail.com> wrote:
>
> Hi.
>
> We already discuss it in another thread. And I want to make little conclusion.
>
> I propose new lock primitives #acquireLock and #tryAcquireLock. They should be based on existed ownership primitives 186 and 187 but with inverted logic.
>
> acquireLock should return true if lock was established by this call. It should return false if lock was already established by current process.
>
> tryAcquireLock should doing same as acquireLock. But if lock already acquired by another process primitive should return nil immediately without waiting.
>
> Eliot, do you already implemented it?
> if you have no time yet could you say me new primitive numbers? And I will try it myself.
>
> It will be nice to get new prims for Pharo5 release.
>
> Best regards,
> Denis
>


Following instructions at https://github.com/pharo-project/pharo-vm
(btw I'm on 32-bit Debian Jessie)

git clone https://github.com/pharo-project/pharo-vm.git
cd pharo-vm
cd image && ./newImage.sh
./pharo-ui generator.image
   PharoVMSpur32Builder buildUnix32.
cd ../build
bash build.sh
../results/pharo  #Needs a spur image

mkdir ../spurImage & cd ../spurImage
curl get.pharo.org/50 | bash
cp ../image/pharo-vm/PharoV40.sources .
cd ../build

bash build.sh
../results/pharo ../spurImage/Pharo.image

------------
../image/pharo-ui ../image/generator.image

searched for implementors of primitiveEnterCriticalSection

In CoInterpreterPrimitives
duplicated primitiveEnterCriticalSection as primitiveAquireOwnedLock
duplicated primitiveExitCriticalSection  as primitiveReleaseOwnedLock

senders of primitiveEnterCriticalSection found...
   StackInterpreter>>initializePrimitiveTable
where I saw...(150 159 primitiveFail)
so for experiment (first time ever playing with this table)
I tried...
    (150 primitiveAquireOwnedLock)
    (151 primitiveReleaseOwnedLock)

  PharoVMSpur32Builder buildUnix32.

bash build.sh
../results/pharo ../spurImage/Pharo.image

-----------------------
Loaded Eliot's CriticalSection.st from [1]...
[1] http://forum.world.st/Where-to-get-Monitor-implementation-based-on-primitives-td4869758.html

>From Pharo5Inbox cherrypicked your
SLICE-Issue-17373-Mutex-should-be-based-on-VM-primitives-and-implement-critical-methods-from-Semaphore--DenisKudryashov.10
* all of OwnedLock as OwnedLock186
* Mutex>>criticalNew: as NewMutex186>>critical:
* Mutex>>initialize as NewMutex186>>initialize

Copied OwnedLock186 & NewMutex186
to OwnedLock150 & NewMutex150.

OwnwedLock150>>acquire
<primitive: 150>

OwnwedLock150>>release
<primitive: 151>

NewMutex150>>initialize
super initialize.
lock := OwnedLock150 new

NewMutex150>>critical: aBlock
^[
lock acquire.
aBlock value
] ensure: [lock release].

Adapted performance tests from [1]...

{Mutex. Monitor. CriticalSection. NewMutex186. NewMutex150} collect:
[:csClass | | n |
n := 0.
   cs := csClass new.
([cs critical: [n := n + 1]. cs critical: [n := n + 1]. cs critical:
[n := n + 1]. cs critical: [n := n + 1]. cs critical: [n := n + 1].
cs critical: [n := n - 1]. cs critical: [n := n - 1]. cs critical: [n
:= n - 1]. cs critical: [n := n - 1]. cs critical: [n := n - 1].
n ] bench),' -> ' , cs class name ]

which sorted gave...
'264,486 per second -> Mutex'
'405,653 per second -> Monitor'
'516,199 per second -> NewMutex186'
'520,167 per second -> NewMutex150'
'686,169 per second -> CriticalSection'

Yay! I added (err, copied) my first primitive.