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. > > > >
