[chuck-users] Time doubt...

[Stefan Blixt]

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 at gmail.com> wrote:

> On 01/08/2012, John Gamboa <vaulttech at 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 at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>



-- 
Release me, insect, or I will destroy the Cosmos!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20120802/441e2c2c/attachment.html>