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

Denis Kudriashov dionisiydk at gmail.com
Mon Feb 15 15:08:15 UTC 2016


Hi Ben.

Do you commit your changes?

2016-02-05 8:34 GMT+01:00 Ben Coman <btc at openinworld.com>:

>
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160215/61c47bca/attachment.htm


More information about the Vm-dev mailing list