[chuck-users] Time doubt...

John Gamboa vaulttech at gmail.com
Tue Jul 31 19:35:52 EDT 2012

Hello again...

Sorry for asking "foolishness": reading the Thesis I think I found the

(The answer, in case I wasn't alone -- please, correct me if I am wrong):
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").

Anyway... very nice! I am really excited about the language lately \o/


2012/8/1 John Gamboa <vaulttech at gmail.com>

> Hello Chuckist...
> 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.
> I was reading the Ge's PhD Thesis and I found this part:
> A ChucK shred must voluntarily relinquish the processor for other shreds to
>> run (In this they are like non-preemptive threads). [...] Shreds, by
>> design,
>> directly use ChucK’s timing mechanism: when a shred advances time or waits
>> for an event, it is, in effect, shreduled by the shreduler (which
>> interacts with
>> the audio engine), and relinquishes the processor. This is powerful in
>> that
>> it can naturally synchronize shreds to each other by time, without using
>> any
>> traditional synchronization primitives.
> 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.
> 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 =)
> --
> John Gamboa
> rabanetescebolas.blogspot.com

John Gamboa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20120801/0769ad8f/attachment.htm>

More information about the chuck-users mailing list