Author |
Message |
Monib
Joined: Oct 11, 2017 Posts: 2 Location: Universal
|
Posted: Wed Oct 11, 2017 11:18 pm Post subject:
Chuck Race Conditions? Subject description: Can Chuck run into race conditions? |
|
|
Hi Guys, I'm somewhat of a newbie to Chuck, and trying to get my head around it. I've been going through the code examples from the Kadenze course as well as the book, and I think I'm hitting a race condition between spork blocks. I've attached modified code from the book.
Essentially, I created three sporks that wait for a signal, which are signaled through a for loop. After that, the broadcast is done, just to show the different behaviors of signal/broadcast methods.
Code: |
//Create an event
Event foo;
//Function triggered by an event.
fun void bar ( Event anEvent, string msg, float freq ) {
Impulse imp => ResonZ rez => dac;
50 => rez.Q;
while ( 1 ) {
//Wait for anEvent
anEvent => now;
//Act on the event
<<< "Event occured @", now/second, "seconds" >>>;
<<<msg>>>;
freq => rez.freq;
50 => imp.next;
}
}
//spork foo -- Each bar goes into infinite loop however
// signal works on only one event, causing sequential actions.
spork ~ bar(foo, "foo event caused bar 1 ... ", 500.0);
spork ~ bar(foo, "foo event caused bar 2 ... ", 700.0);
spork ~ bar(foo, "foo event caused bar 3 ... ", 900.0);
//signa the event in a forever loop
while (1) {
//fire the event sequentially then broadcast
//This is need for a race condition
//1::ms=>now;
for (1 => int i; i <= 3; i++) {
//Signal occurs sequentially based on spork order
<<< "Signalling bar: ", i , now/second >>>;
foo.signal();
//advance time
1::second=>now;
}
<<< "Done with signal for loops." >>>;
//Broadcast occurs in parallel regardless of spork order
foo.broadcast();
//advance time
1::second=>now;
<<< "Done with single broadcast." >>>;
}
|
If I run the code with these lines commented out:
Code: |
//This is need for a race condition
//1::ms=>now;
|
Then the output is not sequential, it misses the other sporks (only signaling bar 1), and causes unexpected behavior like the double signal at the beginning. Here is the output:
Code: |
[chuck](VM): sporking incoming shred: 2 (EventsSignals)...
Signalling bar: 1 2.442667
Signalling bar: 2 3.442667
Event occured @ 3.442667 seconds
"foo event caused bar 1 ... " : (string)
Signalling bar: 3 4.442667
Event occured @ 4.442667 seconds
"foo event caused bar 1 ... " : (string)
"Done with for loop" : (string)
Signalling bar: 1 5.442667
Event occured @ 5.442667 seconds
"foo event caused bar 1 ... " : (string)
Signalling bar: 2 6.442667
Event occured @ 6.442667 seconds
"foo event caused bar 1 ... " : (string)
|
If I add the 1::ms delay, the expected happens:
Code: |
[chuck](VM): sporking incoming shred: 18 (EventsSignals)...
Signalling bar: 1 585.786271
Event occured @ 585.786271 seconds
"foo event caused bar 1 ... " : (string)
Signalling bar: 2 586.786271
Event occured @ 586.786271 seconds
"foo event caused bar 2 ... " : (string)
Signalling bar: 3 587.786271
Event occured @ 587.786271 seconds
"foo event caused bar 3 ... " : (string)
"Done with signal for loops." : (string)
Event occured @ 588.786271 seconds
"foo event caused bar 1 ... " : (string)
Event occured @ 588.786271 seconds
"foo event caused bar 2 ... " : (string)
Event occured @ 588.786271 seconds
"foo event caused bar 3 ... " : (string)
"Done with single broadcast." : (string)
|
Why does this happen?
Thanks,
Monib |
|
Back to top
|
|
|
Antimon
Joined: Jan 18, 2005 Posts: 4145 Location: Sweden
Audio files: 371
G2 patch files: 100
|
Posted: Thu Oct 12, 2017 11:25 pm Post subject:
|
|
|
Hm do the chuck docs claim that shreds that start waiting at the same time will be called in a defined order?
Anyway, one guess at what happens with the 1::ms wait commented out:
1) you spork the three shreds, but none of them have started executing yet, since no wait ahs happened.
2) you signal the event and wait 1 second in the main shred
3) the first shred starts executing, it creates the Impulse and chucks it to rez then dac, it assigns a value to rez.Q, it enters the while loop then hits the wait, which doesnt fire because the event was triggered before this shred started initializing
4) same thing happens for shred 2 and 3
...so that explains why the first signal isn't caught by anyone.
I can't explain why one shred #1 gets any action after that, but as I say, I'm not sure that the ChucK docs claim that shreds that start waiting at the same time are supposed to execute in any particular order. _________________ Antimon's Window
@soundcloud @Flattr home - you can't explain music |
|
Back to top
|
|
|
djay
Joined: May 28, 2014 Posts: 2 Location: france
|
Posted: Sun Oct 15, 2017 2:53 am Post subject:
|
|
|
Just my two cents:
Isn't this what is for? |
|
Back to top
|
|
|
Antimon
Joined: Jan 18, 2005 Posts: 4145 Location: Sweden
Audio files: 371
G2 patch files: 100
|
Posted: Sun Oct 15, 2017 5:53 am Post subject:
|
|
|
Ah yes, I was wondering if there was such an operator, thanks.
IMO, the best approach when you starting spawning shreds at program startup like this, is to keep everything in shreds, and only keep initial sporking and the endless while-loop in the main shred. _________________ Antimon's Window
@soundcloud @Flattr home - you can't explain music |
|
Back to top
|
|
|
|