[chuck-users] Question on Shred Scheduling

[Mike McGonagle]

Thank you, Spencer, while my post was probably a little disjointed,
and my code example did have the missing time settings (I forgot it in
my haste), I think you are right about looking into using events.
Guess it is time for a little more study on events.

And as far as the request for the mutex stuff in ChucK, might the
"synchronize" keyword from Java do the trick? (Yes, I know it is not
that simple, but at least it is a model to follow).

Thanks again,

Mike


On 6/12/06, Spencer Salazar <ssalazar at princeton.edu> wrote:
> Howdy,
>
> On Jun 12, 2006, at 2:44 PM, Mike McGonagle wrote:
> > So, what I would like to know is how the following code would execute.
> >
> > now + 0::ms => now;
> >
> > Would this push the execution of the code to follow to the end of the
> > current time slice? Or is this functionality undefined, and would it
> > execute these shreds in an arbitrary fashion?
>
> Im not sure what that would do, but check out me.yield(), I think
> that serves exactly such a purpose.
>
> > (this is embedded in an object)
> > false => int locked;
> > false => int keepGoing;
> > MController @ controllers[];  // this gets initialized to match the
> > number of controlled parameters
> >
> > fun void helper(....) {
> >    true => keepGoing;
> >    while(keepGoing) {
> >       while(locked) {
> >          now + 0::ms => now;
> >       }
> >       true => locked;
> >       for(0 => int i; i < controllers.cap(); i++) {
> >          if (controllers[i] != null) {
> >             <<< "do something with this controller", "" >>>;
> >          }
> >       }
> >       false => locked;
> >    }
> > }
>
> Hmm, i see a few potential issues here.  helper() never allows for
> the passage of time, which might be a problem, unless keepGoing is
> set to false relatively quickly.  If time doesnt advance within the
> helper shred, time cant advance for other shreds.
>
> Secondly, I dont think your locking mechanism is guaranteed to work
> all of the time.  In this code:
>
> >       while(locked) {
> >          now + 0::ms => now;
> >       }
> >       // point A
> >       true => locked;
>
> what if another shred is scheduled to execute at point A?   Say this
> shred is also waiting on locked; when it is scheduled to execute,
> locked is false, so it exits from the while loop.  Both shreds would
> then proceed as if they had acquired the lock, which is probably
> undesirable.
>
> Its not really possible to write a reliable mutex using standard
> control structures and variables.  It might be possible using Events,
> but I think they are really something that should be provided by the
> ChucK language (feature request!).  Until that happens, I would
> recommend trying to use Events somehow...
>
> spencer
>
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>


-- 
Help the Environment, Plant a Bush back in Texas!