Hello again...<br><br>Sorry for asking "foolishness": reading the Thesis I think I found the answer.<br><br>(The answer, in case I wasn't alone -- please, correct me if I am wrong):<br>It seems that there will just be one shred that will "win" (i.e., that will be the last one shreduled by the shreduler and thus the last one to change the variable). It seemed that the shreduler simply doesn't care with this case: it has a list of waiting-to-be-shreduled shreds and it shreds them blindly until the end. I was also surprised that it also only has as "time information" the number of samples passed since the beginning of the program (I didn't know: I was very curious about how Chuck does its "strongly timed magic").<br>
<br><br>Anyway... very nice! I am really excited about the language lately \o/<br><br>Bye!<br><br><div class="gmail_quote">2012/8/1 John Gamboa <span dir="ltr"><<a href="mailto:vaulttech@gmail.com" target="_blank">vaulttech@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 =)<span class="HOEnZb"><font color="#888888"><br>

<br>-- <br>John Gamboa<br><a href="http://rabanetescebolas.blogspot.com" target="_blank">rabanetescebolas.blogspot.com</a><br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br>John Gamboa<br><a href="http://rabanetescebolas.blogspot.com">rabanetescebolas.blogspot.com</a><br>