This seems resolved, but I feel a desire to throw in my own answer for this question anyway: Q: 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? A: Two shreds will never try to change a particular variable at the same time, because two shreds can't run at the same time. If one shred is running it will not allow any other shred to do anything unless it says so, by issuing a wait statement (e.g. 1::ms => now) or yield. One effect of this rule is that if a shred changes the value of global variable x, it can count on x staying as it is until it either changes x again or issues a wait statement. So there's no need to worry about the kind of complicated structures you usually have to set up with threading in other languages, like monitors and other synchronization stuff. On Wed, Aug 1, 2012 at 2:19 PM, Kassen wrote:

On 01/08/2012, John Gamboa wrote:

...

Hello again...

Hey John,

...

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

It's not "foolish", it's a important question, at the core of ChucK's structure. It's easy to miss the "formal" answer, because the behaviour it leads to is quite natural most of the time and makes it "just work". Let's Have a look.

...

(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").

Yes, that is correct. Only one shred runs at a time and our syntax specifies in what way they take turns. All the above is correct, but it seems to imply that if shred A and shred b are "shreduled" to run at the same time T then we just get whatever. That is not true; if shred A was handed to the shreduler first then it will also run first, in your particular case that will mean that shred B gets to set the variable. Whether doing that in such a way is smart is another question, of course. When no shreds are computing the UGen- Graph gets to use the CPU.

This leads to some interesting things. You may have noted that "dur" and "time" are double-floats (like many things in ChucK), making us able to reason about time spans considerably shorter than the period between two clock pulses of your CPU. That sounds silly, until we realise that we are really talking about the order in which stuff runs, not the moment at which it does.

So; ChucK's execution order is (or should be...) deterministic at all times and better yet; with some care in writing it will also be easily predictable to you.

...

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

Great! Have fun, share results and tricks, report bugs :-)

Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- Release me, insect, or I will destroy the Cosmos!