Hello Chuckist...<br><br>I'm relatively new to Chuck -- although I'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'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 ("rounded" 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't understand exactly what would happen at that point D=. I imagine that the occurrence of such event is very unlikely (there are "a lot" of samples in one second), but supposing that the computation in Chuck really takes "no time" 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'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>