[Vm-dev] [ANN] ARM Stack VMs available

[David T. Lewis]

Is it possible to turn this into a unit test that would fail on the ARM VM?

I'm thinking of a test that might set up some processes to run at some
otherwise unused scheduling priority, and that would assert that the
expected process is resumed after having been interrupted by a higher
priority process.

Dave

>
> Hi Folks,
>
> The Squeak process scheduler usually preempts a process only by
> another one of higher priority. And when the scheduler is ready to go
> back at the lower priority, it will always resume the same process
> that was last suspended. The only way for two or more processes of the
> same priority to share the processor is when the running process calls
> #wait or #yield.
>
> This means that using shared state from several processes at the same
> priority (without using any locking mechanism, such as Semaphores,
> Monitors or critical sections) is safe, as long as the processes do
> #wait or #yield only when that shared state is in a consistent state.
>
> It looks like this ARM VM is somehow not following this convention. If
> this was the case, the problems Ken sees are to be expected.
>
> HTH,
> Juan Vuletich
>
> Quoting Douglas McPherson <djm1329 at san.rr.com>:
>
>> Hi Ken,
>>
>>> On Nov 11, 2014, at 16:28, Ken Dickey <Ken.Dickey at whidbey.com> wrote:
>>>
>>>
>>> On Sun, 9 Nov 2014 20:56:47 -0800
>>> Douglas McPherson <djm1329 at san.rr.com> wrote:
>>>
>>> KenD>>
>>>>> The stkspurlinuxhtARM VM, however, complains:
>>>>> This interpreter (vers. 6521) cannot read image file (vers. 6505).
>>>>>
>>>>> I presume some conversion is required to get the image into SPUR
>>>>> format?
>>>>>
>>>> Yes, the Spur VMs require a new image format. There are recent
>>>> Squeak trunk images in the spur format on Eliot’s site. I’ll let
>>>> Eliot and others comment about how a Cuis image might be converted.
>>>
>>> I tried out the Squeak SPUR image from the Cog site and everything
>>> Squeak seems fine.
>>>
>>>
>>> There is a timing bug with Cuis redraw that shows up on both the
>>> stklinuxhtARM vm and the one you sent me earlier.
>>>
>>> Basically, I am using DisplayObject>>slideFrom:to:nSteps:delay: to
>>> do some animation.  When multiple timer events fire during an
>>> animation it sometimes appears that the x,y redraw origin is used
>>> from the currently drawing morph's position, not 0,0.  I.e. part of
>>> the redisplay is offset.  [Display redraw via menu corrects the
>>> display].
>>>
>>> This _only_ happens on the Samsung ARM Chromebook, never on Intel CPUs.
>>>
>>
>> Thanks for reporting this. I’ll try to look into it. There are
>> definitely ARM-specific changes to support certain atomic
>> operations, so there may be something not quite right with these.
>>
>> Can you suggest a method for reproducing this in Squeak? I
>> repeatedly sent morphs to the trash (with appropriate preference set
>> to enable the animation) but didn’t see an issue. I suspect I’m not
>> driving it hard enough.
>>
>>> My life is really, really busy right now, so I have never had time
>>> to dig into this.  I can redraw the display, so a workaround exists.
>>>
>>> [One possible resource.  The Apache Portable Runtime,
>>> http://apr.apache.org/ , implements compareAndSwap and various
>>> other atomic operations across various OSs.]
>>>
>>
>> Thanks for the reference. It may be useful. I also found a library
>> called Mintomic
>> (http://preshing.com/20130505/introducing-mintomic-a-small-portable-lock-free-api/)
>> which may
>> help.
>>
>>> I am happy to do quick tests, but must apologize for lack of time
>>> to dig into this.
>>>
>>
>> No problems, and thanks again for reporting it.
>>
>>
>>> FYI,
>>> -KenD
>
>
>