electro-music.com   Dedicated to experimental electro-acoustic
and electronic music
 
    Front Page  |  Radio
 |  Media  |  Forum  |  Wiki  |  Links
Forum with support of Syndicator RSS
 FAQFAQ   CalendarCalendar   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   LinksLinks
 RegisterRegister   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in  Chat RoomChat Room 
 Forum index » DIY Hardware and Software » ChucK programming language
Chuck Race Conditions?
Post new topic   Reply to topic Moderators: Kassen
Page 1 of 1 [4 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
Author Message
Monib



Joined: Oct 11, 2017
Posts: 2
Location: Universal

PostPosted: Wed Oct 11, 2017 11:18 pm    Post subject: Chuck Race Conditions?
Subject description: Can Chuck run into race conditions?
Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message
Antimon



Joined: Jan 18, 2005
Posts: 4145
Location: Sweden
Audio files: 371
G2 patch files: 100

PostPosted: Thu Oct 12, 2017 11:25 pm    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message Visit poster's website
djay



Joined: May 28, 2014
Posts: 2
Location: france

PostPosted: Sun Oct 15, 2017 2:53 am    Post subject: Reply with quote  Mark this post and the followings unread

Just my two cents:
Isn't this what
Code:
me.yield()
is for?
Back to top
View user's profile Send private message
Antimon



Joined: Jan 18, 2005
Posts: 4145
Location: Sweden
Audio files: 371
G2 patch files: 100

PostPosted: Sun Oct 15, 2017 5:53 am    Post subject: Reply with quote  Mark this post and the followings unread

Ah yes, I was wondering if there was such an operator, thanks. Smile

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
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic Moderators: Kassen
Page 1 of 1 [4 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
 Forum index » DIY Hardware and Software » ChucK programming language
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Forum with support of Syndicator RSS
Powered by phpBB © 2001, 2005 phpBB Group
Copyright © 2003 through 2009 by electro-music.com - Conditions Of Use