I hate to bust this old evilness out, but is it feasible to abuse
#become: for this purpose?  I haven't used it in so long I don't
actually remember whether that's feasible semantics with ivars.

On Thu, Apr 3, 2014, at 09:08 AM, Levente Uzonyi wrote:
> On Thu, 3 Apr 2014, Igor Stasenko wrote:
> 
> > 
> > 
> > 
> > On 3 April 2014 00:11, Sven Van Caekenberghe <s...@stfx.eu> wrote:
> >       Hi,
> >
> >       Is it possible to have a simple lock-free atomic counter in Pharo 3.0 
> > ?
> >
> >       nextId
> >         ^ idCounter := idCounter + 1
> >
> >       Or is it still possible that two process entering this code can mess 
> > things up ?
> > 
> > #+ is a message send. So technically, if you will be interrupted at the 
> > point of
> 
> If #+ is compiled to bytecode 176, and both the receiver and the argument 
> are SmallIntegers, then it's not a message send, so the operation is 
> atomic.
> 
> 
> Levente
> 
> > returning a result from it, then somebody else could run #nextId without 
> > notice,
> > as result you will get 2 processes returning same value from #nextId.
> > (and increasing numbers of concurrent processes will produce even more 
> > surprising results :)
> >  
> >       I vaguely remember a discussion about that long ago...
> > 
> > assignment is atomic.. the one which i use in atomic queue impl., but it is 
> > hidden, undocumented VM implementation detail :) e.g.:
> > 
> > oldA := a.
> > a := newA.
> > ..
> > actually can be any series of it, as long as nothing else there (no message 
> > sends)
> > 
> > x:= a.
> > y:=b.
> > z := c.
> > w := e.
> > 
> > will be performed atomically.
> > 
> >  
> >       TIA,
> >
> >       Sven
> > 
> > 
> > 
> > 
> > --
> > Best regards,
> > Igor Stasenko.
> > 
> >

Reply via email to