(inline)

Quoting Eliot Miranda <eliot.miranda at gmail.com>:

> Hi Juan,
>
>
> On Dec 5, 2014, at 4:56 AM, "J. Vuletich (mail lists)"
> <juanlists at jvuletich.org> wrote:
>
>> 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.
>
> No.  According to the blue book preempting sends the preempted process
> to the back if its run queue so preempting forces a yield.  Obviously
> this is wrong, but that's the way it was defined.  The ObjectWorks &
> VisualWorks VMs changed this to work as you describe.

Oh, apologies. Thanks for correcting me.

But this means that understanding the problems Ken and Tim found on  
the PI is not that easy, because in other platforms the problem don't  
occur, even with olders VMs and (I guess) on slower machines.

I don't have a PI myself, so I can't do much testing.

Maybe something in the VM timer(s), event fetching, or semaphore  
signaling is different in the PI from others VMs? Or maybe the  
possible interrupt points are different? Maybe something like this  
could make a higher priority process wake up at usual times, or under  
less restricted conditions?

> When I implemented Cog I wanted to fix this but not break old code so
> I made it optional.  The behavior is controlled by a flag in the
> image.  You can see the flags via Smalltalk vmParameterAt: 48.  Bit 2
> (value 4) is set if preempting puts the preempted process at the head
> of its list, and hence does not yield.
>
> Here's the part of the comment from vmParameterAt:
>
>     48 various properties of the Cog VM as an integer encoding an
> array of bit flags.
>         Bit 0: implies the image's Process class has threadId as its
> 3rd inst var (zero relative)
>         Bit 1: on Cog VMs asks the VM to set the flag bit in  
> interpreted methods
>         Bit 2: if set, preempting a process puts it to the head of its
> run queue, not the back,
>                 i.e. preempting a process by a higher one will not
> cause the process to yield
>                 to others at the same priority.
>
>
>> 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.
>
> Right.
>
>>
>> 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.
>
> Can you check the bit is set in the image?
>
>
> Thanks for raising this.  It looks like the Spur images have the bit
> cleared.  Ouch.  Ah, it's not a problem of the bootstrap, its at least
> a problem in trunk.  The bit is not set in trunk.  I need to a) write
> some tests to test the bit and b) make sure its set in the relevant
> places.

Glad to be of help!

Cheers,
Juan Vuletich

>>
>> HTH,
>> Juan Vuletich
>
> Eliot (phone)
>
>> 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