Program Order of Execution

[apostolakisl]

I did an experiment to see how ISY orders its execution of programs. Order of program execution is very important in all of my day, week, month, etc programs. Having them run at 12:00:00, 12:00:01, 12:00:02, etc is kind of sloppy in my mind. So instead I have one program cascade onto the next, having them run in order without risk of something else running in between.

 

For example, if program a runs program b then d, and program b runs program c, would program b cascade to program c, prior to program d running. The answer is yes.

 

I created four programs a, b, c, d

 

Each program sets a variable equal to 1 plus the previous variable starting with 1 for a. So b = a+1, c = b+1, and d = c+1. So if the programs ran in order a,b,c,d then variables a,b,c,d would end up being 1,2,3,4.

 

I had program a run b and d (the then clauses) (in that order)

I had program b run program c. (then clause again)

 

What I found is that the order ran a,b,c,d witnessed by the variable equalling 1,2,3,4 respectively. So, when a program's then clause sends off to another program to run, it will completely run the then clause of that other program and not return to the original program''s next line until it has finished executing all of the then clause of the program it was sent to including getting sent off to other programs.

 

THE EXCEPTION: I put a wait clause into program b. The wait cluase did allow program d to run prior to the completion of program b. This was expected, but I just wanted to confirm.

[Hurting2Ride]

I have been wanting to confirm that same thing but have much too lazy to actually test it. Thanks!

[apostolakisl]

In my mind, when I execute a program from another program in ISY, I think of it the same as executing a subroutine in more conventional programming styles.

[LeeG]

I would not assume the clause of a called Program will run to completion before the calling Program continues. From the UDI Wiki …

 

“Within the Then or Else clause of a program, statements are executed from top to bottom in the order in which they occur. When a statement calls another program, the called program begins executing, and the calling program immediately continues execution with the next statement in sequence--it does not wait for the called program to complete before continuing.â€

 

The tasking of an OS is unpredictable in real life. The various threads in the ISY OS that have priority will change the execution order of that simple test. Without a specific task wait on another task capability Program execution will vary.

[apostolakisl]

I would not assume the clause of a called Program will run to completion before the calling Program continues. From the UDI Wiki …

 

“Within the Then or Else clause of a program, statements are executed from top to bottom in the order in which they occur. When a statement calls another program, the called program begins executing, and the calling program immediately continues execution with the next statement in sequence--it does not wait for the called program to complete before continuing.â€

 

The tasking of an OS is unpredictable in real life. The various threads in the ISY OS that have priority will change the execution order of that simple test. Without a specific task wait on another task capability Program execution will vary.

 

 

Well that's great. So unexplained stuff is going to change the order of operation? So is ISY jumping back and forth? A linear thread from top to bottom would be much preferred. It obviously executes the called program prior to moving on in the example I created, so it is some sort of unpredictable thing?

[LeeG]

There are threads that have higher priority than User Program threads. For example, when Insteon device message traffic enters the picture. Without that a long running Program clause could block other Program execution. Once the currently executing user Program thread has been interrupted by a higher priority thread, how the OS dispatches the lower priority interrupted threads will not be predictable from an individual Program perspective.

 

When Program A “Runs†Program B each Program runs independently on their own thread. A “Call Program B†is the term often given to a thread transferring instruction execution to another Program/subroutine, continuing at the same task/thread level.

 

The only way Program A and Program B can be serialized is to have a "Wait on Program B to complete" or “Wait on Program B to post an event Program A is waiting on†function. That function does not exist at the user Program level. This is standard multi tasking stuff. It applies to every multi tasking OS I have worked with over 40+ years. Nothing unique to the ISY Programming model.

 

An event driven multi thread model is essential with automation. It would certainly make Programming concepts easier if things were linier but that model cannot work in a world based on device button/paddle presses and time specific events.

[apostolakisl]

So even two programs running at 12:00:00 and 12:00:01 could end up not fully executing in order if a bunch of other stuff were going on at once slowing down processing?

 

It sure would be nice if there were some way to force a group of programs to execute in order. Even if some other event got injected in there, if you could know for sure that your stipulated group executed in order that would be nice (ie the subroutine concept). If you have two programs that must execute in a certain order, short of separating them using widely spaced time conditions, there is no way to gaurantee order.

[LeeG]

That is correct. There is no guarantee the Program started at 12:00:00 will complete before the Program started at 12:00:01. They run independently.

[Hurting2Ride]

That is correct. There is no guarantee the Program started at 12:00:00 will complete before the Program started at 12:00:01. They run independently.

 

That is why I have been trying to use "Wait" or to launch program B only after program A completes (a pain in the butt but doable) if B relies on A. Reading the OP I was thinking something had changed in how programs were handled.

 

It would be nice if we had access to "Last Finish Time" and "Next Scheduled Run" in the conditions, and "Next Scheduled Run" in the actions. Would simplify things of this nature.

[apostolakisl]

Well fortunately all of my programs that I have written this way seem to be working despite this fact.

 

But, I really think there should be an option for wait and hold

 

If

- No Conditions - (To add one, press 'Schedule' or 'Condition')

 

Then

Run and pause for finish Program 'x' (Then Path)

 

Else

- No Actions - (To add one, press 'Action')

 

 

 

And regarding hunting2ride comment, the trouble with "wait" is it opens up the program conditions for re-evaluation. But that is a whole other topic that seemed to go on forever a while ago.