<div dir="ltr">Hi Juan & Tim,<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 5, 2014 at 5:04 AM, J. Vuletich (mail lists) <span dir="ltr"><<a href="mailto:juanlists@jvuletich.org" target="_blank">juanlists@jvuletich.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Tim,<br>
<br>
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.<br></blockquote><div><br></div><div>See <a href="http://lists.squeakfoundation.org/pipermail/vm-dev/2014-December/017215.html">http://lists.squeakfoundation.org/pipermail/vm-dev/2014-December/017215.html</a>. Looks like the bit isn't set to ensure preemption doesn't yield. See the preemptionYields[:] accessors.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
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.<br>
<br>
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.<br>
<br>
In any case, if you do your proposed change, please do it in a new method called #<u></u>computeAttackSustainValueAtMSe<u></u>cs: 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.<br>
<br>
HTH,<br>
Juan Vuletich<div class=""><div class="h5"><br>
<br>
Quoting tim Rowledge <<a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>>:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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?<br>
<br>
tim<br>
--<br>
tim Rowledge; <a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>; <a href="http://www.rowledge.org/tim" target="_blank">http://www.rowledge.org/tim</a><br>
Useful random insult:- Calls people to ask them their phone number.<br>
</blockquote>
<br>
<br>
<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">best,<div>Eliot</div></div>
</div></div>