Hello Chuckist...<br><br>I&#39;m relatively new to Chuck -- although I&#39;ve already used it some time ago -- and I have a doubt about how the time works in the VM.<br><br>I was reading the Ge&#39;s PhD Thesis and I found this part:<br>
<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">A ChucK shred must voluntarily relinquish the processor for other shreds to<br>run (In this they are like non-preemptive threads). [...] Shreds, by design,<br>
directly use ChucK’s timing mechanism: when a shred advances time or waits<br>for an event, it is, in effect, shreduled by the shreduler (which interacts with<br>the audio engine), and relinquishes the processor. This is powerful in that<br>
it can naturally synchronize shreds to each other by time, without using any<br>traditional synchronization primitives.<br></blockquote><div></div><div><br>My question is: if two threads try to change the same variable at the same time (&quot;rounded&quot; to the nearest sample), what is the expected behavior of the program? I tried to take a look at the code of the VM, but I couldn&#39;t understand exactly what would happen at that point D=. I imagine that the occurrence of such event is very unlikely (there are &quot;a lot&quot; of samples in one second), but supposing that the computation in Chuck really takes &quot;no time&quot; to happen (as the thesis often reforced), I believe it would happen soon or later.<br>
</div><br>Anyway, I have right now [at least some] interest at how the shreduler works, so I&#39;m possibly gonna spend some time trying to understand exactly what happens at that file. If you have some tip on where I should start, it would make me very happy =)<br>
<br>-- <br>John Gamboa<br><a href="http://rabanetescebolas.blogspot.com">rabanetescebolas.blogspot.com</a><br>