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 <signal.automatique@gmail.com> wrote:
On 01/08/2012, John Gamboa <vaulttech@gmail.com> 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!