Re: [plexil-support] Possible Concurrence bug

[Dalal, M. (ARC-TI)[S. G. T. I. (S. Inc.)] <mic...@na...>]

Catherine,

I'm guessing that, without a print statement or any other command, at least one of your While loops was "spinning", and effectively blocking the executive.  It's easy to imagine that "concurrence" suggests truly parallel execution, but PLEXIL is single-threaded, and if one node has an indefinite Repeat (which is what While compiles to), that node tree, and only that one, will keep executing until the next Macro step.  A Macro step is a synchronous interaction with the external world, such as a command or lookup (see the Semantics chapter, and an article on synchronous languages, for more info).  Your empty 'pprint' effectively forces a Macro step.

>From a design level, polling loops are inefficient.  PLEXIL excels at waiting (monitoring), which is hard to do in many other languages.

Hope this helps,
Mike


On Apr 8, 2014, at 11:00 AM, Catherine Szeto <Cat...@ti...<mailto:Cat...@ti...>>
 wrote:

Hello,
         I noticed that some unusual behavior with Concurrence which may indicate a bug somewhere. Here is my pseudocode:

Concurrence
{
      Monitor:
     {
          while( MainKill == false)
          {
                //pprint("Monitor Cds Iteration");
                MonitorCds:
                {
                      PreCondition ...;
                      //Calls MonitorCds plan
                }
          }//end of while loop
     }//end of Monitor

     Operations:
      {
           while( MainKill == false)
           {
                //pprint("Main Loop Iteration");
           }//end of while loop

           Concurrence
          {...Can call a variety of plans depending on what is issued from UI..}

      }//end of Operations
}//end of Concurrence
Originally we only had Operations which ran fine, but then we needed two while loops running simultaneously and constantly so we used Concurrence.

Here is the bizarre behavior I noticed while experimenting with this structure:

While loops as originally done -- no response from UI
RepeatCondition instead of while loop -- exact same behavior as above

I used pprint statements to try to debug the issue. I placed the statements where I have them commented out in my pseudo code.
pprint statement at every while loop iteration -- normal, expected behavior, but since the iterations are quick this results in a lot of output print statements.
pprint statement at every while loop iteration  at time interval of 60 sec  -- very slow response from plans called by UI
pprint statement at every while loop iteration  at time interval of 10 sec  -- quicker response than the 60 sec interval test, but still slow.

Resolution: I eventually resolved the issue by issuing a blank print statement (print("")) at every loop iteration for both while loops. I now get the normal behavior as I expected.

Catherine
------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees_______________________________________________
plexil-support mailing list
ple...@li...<mailto:ple...@li...>
https://lists.sourceforge.net/lists/listinfo/plexil-support