On Thu, Aug 7, 2014 at 10:00 PM, Ryan Macnak <rmacnak at gmail.com> wrote:

>
> On Thu, Aug 7, 2014 at 8:43 PM, Ben Coman <btc at openinworld.com> wrote:
>>
>> I am looking at dealing with multiple in-image threads and am wondering
>> about what operations are atomic.  The current understanding is that...
>>    (myvar == nil) ifTrue: [ myvar := 1.  myvar2 := #something ]
>> is atomic, but I see some indication in comments (sorry lost my
>> reference) that...
>>    myvar ifNil: [ myvar:=1 ]
>> might not be - but maybe those comments were historical. What is the
>> current status and likely future guarantees for Squeak/Pharo/Cuis/other?
>
>
> On Squeak-derived systems the two operations that are not atomic are
> message sends and backward branches; these are where the VM checks for
> external events and your process might be preempted by one with a higher
> priority.
>

That's very close.  In fact, the two places where the VM tests for events
are sends that build a frame and backward branches.  So a send that
activates a method that has a primitive that doesn't fail won't check for
events.  Quick primitives are used to answer inst vars of all objects
except contexts, so any inst var fetch of a non-context can be done without
a process switch.


> #ifTrue: and #ifNil: are atomic because the bytecode compiler inlines them
> (#ifTrue: has always been inlined, but I don't think #ifNil: always was).
>

That's right.


> #== is atomic because the VM implements it without a send.
>

And it would still be atomic if sent since it will bind to a non-failing
primitive.

This is all if code runs normally. If run through the debugger you might be
> interrupted at any operation because the simulation is implemented in terms
> of Smalltalk code with tons of sends. One should not rely on these
> implementation details and instead use semaphores or (very rarely)
> #valueUnpreemptively.
>

It's very useful for experiments to know what one can get away with.  But
the language could add some atomicity operation such as conditional
assignment, and that could still be safe if debugged. e.g. (myVar ?== nil
:= 1) would be a nice syntax, setting myVar to 1 if it is == to nil.  Nice
too if this evaluated to a boolean, true if the assignment occurred.

-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140810/ec0323e9/attachment.htm