[squeak-dev] Re: Sound playing can break in odd manner

Eliot Miranda eliot.miranda at gmail.com
Fri Dec 5 17:57:07 UTC 2014


Hi Juan & Tim,

On Fri, Dec 5, 2014 at 5:04 AM, J. Vuletich (mail lists) <
juanlists at jvuletich.org> wrote:

> Hi Tim,
>
> 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.
>

See
http://lists.squeakfoundation.org/pipermail/vm-dev/2014-December/017215.html.
Looks like the bit isn't set to ensure preemption doesn't yield.  See the
preemptionYields[:] accessors.


>
> 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, this kind of problems could arise. I just answered with
> the same text to a thread in VM-Dev, where the problem shows up when doing
> Morphic stuff (in Cuis) from two different processes of the same priority.
> Seeing it again in a different part of a different system, but on the same
> platform made me realize it must be a VM issue.
>
> In any case, if you do your proposed change, please do it in a new method
> called #computeAttackSustainValueAtMSecs: or such. #computeValueAtMSecs:
> is used (at least in Cuis, jm 2/4/98) in #showOnDisplay, that draws the
> envelope including the decay phase. But if I'm right, until the assumption
> on the behavior of the scheduled is 'fixed', more weird shared state
> problems will arise.
>
> HTH,
> Juan Vuletich
>
>
> Quoting tim Rowledge <tim at rowledge.org>:
>
>  To partly answer my own question, I just noticed that
>> Envelope>computeValueAtMSecs: is only sent by Envelope>sustainEnd: and thus
>> that first clause must always get skipped (because we always call it with
>> loopEndMSecs== nil) and so surely we’d be ok to delete that bit and not
>> mess around with the ‘pretend to be sustaining’ stuff?
>>
>> tim
>> --
>> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>> Useful random insult:- Calls people to ask them their phone number.
>>
>
>
>
>
>


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


More information about the Squeak-dev mailing list