Re: [plexil-support] Possible Concurrence bug

[Catherine S. <Cat...@ti...>]

Thanks Mike, that does clear things up. We did have an earlier conversation over Concurrence, though the situation was slightly different. In the previous conversation, you suggested that a StartCondition would be better for a node that is monitoring another node. It worked great for that situation, but the difference is that the Monitor node here must be able to execute multiple times, i.e. not just execute once and be done. That's why we put in the while loops. Would using RepeatConditions instead of while loops make any difference in the back-end of the PLEXIL, even though on the outside it seems to perform exactly the same way as the while loop? Any other ideas to make this situation more "Plexil-efficient" would be welcome as well.

Catherine

From: Dalal, Michael (ARC-TI)[Stinger Ghaffarian Technologies Inc. (SGT Inc.)] [mailto:mic...@na...]
Sent: Tuesday, April 08, 2014 3:58 PM
To: Catherine Szeto
Cc: ple...@li...
Subject: Re: [plexil-support] Possible Concurrence bug

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