[Vm-dev] Can we invert logic of critical section primitives (186, 187)?

[Eliot Miranda]

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 <dionisiydk at gmail.com> 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?