Can we invert logic of critical section primitives (186, 187)?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Can we invert logic of critical section primitives (186, 187)?

Denis Kudriashov
 
Hi.

Current logic is:

- primitiveEnterCriticalSection returns true if section is already entered inside same Process (when recursive call happens). It returns false when new lock on critical section acquired
- primitiveTestAndSetOwnershipOfCriticalSection returns true if section is already entered inside same Process (when recursive call happens). It returns false when new lock on critical section acquired. It returns nil when section locked by other process.

Users of this code must handle process termination carefully which required local variable which track current lock state:

[lockState := section primitiveEnterCriticalSection.
some code]
   ensure: ["condition around lockState" section primitiveExitCriticalSection ]

With current logic of primitives it is not easy to give this variable intuitive name. You can't name it exitRequired or sectionEnteredHere because primitive returns opposite value.

Can we invert this primitive return values? It will make users code cleaner and easy to understand.

This primitives are not used in Pharo or Squeak yet. I push change for Pharo. But now I have thoughts that it is better to change primitives before we will start use it.

What you think?
Reply | Threaded
Open this post in threaded view
|

Re: Can we invert logic of critical section primitives (186, 187)?

Eliot Miranda-2

Hi Denis,

    I'm sorry but I already moved Squeak trunk over to the new primitives (and 3DICC's Terf system has been using them since 2008/2009).  You can invert via eg

    false == self primitiveEnterCriticalSection

At some future date we could add revised primitives with new primitive numbers. But the current primitives are set.  Sorry.

_,,,^..^,,,_ (phone)

> On Jan 11, 2016, at 8:35 AM, Denis Kudriashov <[hidden email]> wrote:
>
> Hi.
>
> Current logic is:
>
> - primitiveEnterCriticalSection returns true if section is already entered inside same Process (when recursive call happens). It returns false when new lock on critical section acquired
> - primitiveTestAndSetOwnershipOfCriticalSection returns true if section is already entered inside same Process (when recursive call happens). It returns false when new lock on critical section acquired. It returns nil when section locked by other process.
>
> Users of this code must handle process termination carefully which required local variable which track current lock state:
>
> [lockState := section primitiveEnterCriticalSection.
> some code]
>    ensure: ["condition around lockState" section primitiveExitCriticalSection ]
>
> With current logic of primitives it is not easy to give this variable intuitive name. You can't name it exitRequired or sectionEnteredHere because primitive returns opposite value.
>
> Can we invert this primitive return values? It will make users code cleaner and easy to understand.
>
> This primitives are not used in Pharo or Squeak yet. I push change for Pharo. But now I have thoughts that it is better to change primitives before we will start use it.
>
> What you think?
Reply | Threaded
Open this post in threaded view
|

Re: Can we invert logic of critical section primitives (186, 187)?

Denis Kudriashov
 
Hi Eliot.

2016-01-11 18:00 GMT+01:00 Eliot Miranda <[hidden email]>:
Hi Denis,

    I'm sorry but I already moved Squeak trunk over to the new primitives (and 3DICC's Terf system has been using them since 2008/2009).  You can invert via eg

    false == self primitiveEnterCriticalSection

At some future date we could add revised primitives with new primitive numbers. But the current primitives are set.  Sorry.

Ok. I can not wait this for now. 
So we will integrate my changes into Pharo (I hope)
Reply | Threaded
Open this post in threaded view
|

Re: Can we invert logic of critical section primitives (186, 187)?

Levente Uzonyi
 
On Mon, 11 Jan 2016, Denis Kudriashov wrote:

> Ok. I can not wait this for now. 
> So we will integrate my changes into Pharo (I hope)

That was the time when Pharo finally separated at the VM level.

Levente
Reply | Threaded
Open this post in threaded view
|

Re: Can we invert logic of critical section primitives (186, 187)?

EstebanLM
 
no he is not.
he is talking about the image.

do not drop bombs :)

Esteban

> On 11 Jan 2016, at 22:35, Levente Uzonyi <[hidden email]> wrote:
>
> On Mon, 11 Jan 2016, Denis Kudriashov wrote:
>
>> Ok. I can not wait this for now.
>> So we will integrate my changes into Pharo (I hope)
>
> That was the time when Pharo finally separated at the VM level.
>
> Levente

Reply | Threaded
Open this post in threaded view
|

Re: Can we invert logic of critical section primitives (186, 187)?

Denis Kudriashov
In reply to this post by Levente Uzonyi
 

2016-01-11 22:35 GMT+01:00 Levente Uzonyi <[hidden email]>:
On Mon, 11 Jan 2016, Denis Kudriashov wrote:

Ok. I can not wait this for now. 
So we will integrate my changes into Pharo (I hope)

That was the time when Pharo finally separated at the VM level.

Sorry.
I mean I will not wait primitive changes and just push my image code with current semantic