are a series of statments within a "THEN" clause still "atomic"?

[someguy]

 

 

Statement Execution Order

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.

A series of statements within a Then clause (or within an Else clause), up to the next Wait or Repeat statement, are atomic. In other words, all such statements are executed before the conditions of the program are retested. The program's conditions are reevaluated each time a Wait or Repeat statement is encountered, and at the end of each iteration of a Repeat loop.

What this means is that if a program's Then clause changes a condition which causes the program's overall condition to become false (or if the program's Else clause changes a condition which causes the program's overall condition to become true), the current atomic statement group will complete, and at that point execution will transfer from the Then clause (or the Else clause) to the Else clause (or the Then clause).

Therefore, if a Then clause (or an Else clause) contains no Wait or Repeat statements, the entire clause is atomic, and will complete before the program's conditions are reevaluated.

(this is from the Wiki)

 

is this still true?  I've tried running a program that says  

 

if x light is on

 

then

 

turn x light off

turn x light on

turn x light off

turn x light on

 

and as soon as the first "off" happened the program stopped running.  Maybe this was a change that was made in how the programming works.  When it did this, it was maybe 8 years ago.  

[stusviews]

The logic of sequential steps is still valid. The reason your program stops is that as soon as the first step is executed, the condition is rendered false and execution ceases. You can achieve the result you want by creating two programs as follows:

 

Program 1

if x light is on

 

then

        run program 2 (then)

 

Program 2

if (no condition)

 

then

        turn x light off

        turn x light on

        turn x light off

        turn x light on

[oberkc]

I understood that a program such as this would continue to the end, unless it had wait, or repeats, in the statement.  A change in the condition would NOT halt it, I thought.

 

Perhaps this aspect has changed.  Certainly, I would try stusviews recommendations.

[someguy]

yes, stusviews, but here is an excerpt:  

 

 

A series of statements within a Then clause (or within an Else clause), up to the next Wait or Repeat statement, are atomic. In other words, all such statements are executed before the conditions of the program are retested. The program's conditions are reevaluated each time a Wait or Repeat statement is encountered, and at the end of each iteration of a Repeat loop.

[bipto]

_{I'm thinking this wiki excerpt doesn't hold true in cases where the IF clause contains a device / program status or state variables.  In such cases the IF is immediately re-evaluated if any of those elements change.  Much of my programming relies on this feature.}

 

_{Correct me if I'm wrong...}

Edited September 25, 2017 by bipto

[apostolakisl]

The issue is you have conflicting actions.  All items in a "then" clause that are not separated by a wait or repeat theoretically happen simulatneously.  So your program is causing some logic issues in ISY being that it is trying to exectue different actions on the same device simultaneously.

 

In addition, a "then" clause should not be considered to run from top to bottom.  Experimentally, I have deteremined that it typically does by doing some math functions where order of oprations affects the results, but like I said, not always.

[stusviews]

The issue is you have conflicting actions.  All items in a "then" clause that are not separated by a wait or repeat theoretically happen simulatneously.  So your program is causing some logic issues in ISY being that it is trying to exectue different actions on the same device simultaneously.

 

In addition, a "then" clause should not be considered to run from top to bottom.  Experimentally, I have deteremined that it typically does by doing some math functions where order of oprations affects the results, but like I said, not always.

 

My understanding of programs is that they are consistent, they never vary. That's a goal of programming, always achieving the same result. Unless of course the program itself causes a change.

[apostolakisl]

My understanding of programs is that they are consistent, they never vary. That's a goal of programming, always achieving the same result. Unless of course the program itself causes a change.

 

I don't know that whay you say is true.   I do know that you can't write a "then" clause with mutually exclusive commands unless you separte them with a wait.  A light can't be set to on and off simultanously (twice each no less).

 

In all likelihood, you would see the same behavior each time a "race" program such as above is run.  However, it wouldn't surprise me that if you ran multiple programs simultaneously that the processor might treat one of these "race" situations differently and give a different outcome.

 

Regardless, the above program or any like it serves no purpose, so I'm not sure why it was ever written in the first place.  

[stusviews]

The program does, in fact, run correctly. The OP only specified, "if x light is on." I don't know if that's possible in v5+. but it's not in v4+. In particular, v4+ requires that an if statement include "Control" or "Status." The program referred to has neither.

[oberkc]

The program does, in fact, run correctly. The OP only specified, "if x light is on." I don't know if that's possible in v5+. but it's not in v4+. In particular, v4+ requires that an if statement include "Control" or "Status." The program referred to has neither.

 

I took the program listing as conceptual, not using strict syntax.  For the purpose of someguy's question, that was sufficient in my mind.

[apostolakisl]

The logic of sequential steps is still valid. The reason your program stops is that as soon as the first step is executed, the condition is rendered false and execution ceases. You can achieve the result you want by creating two programs as follows:

 

Program 1

if x light is on

 

then

        run program 2 (then)

 

Program 2

if (no condition)

 

then

        turn x light off

        turn x light on

        turn x light off

        turn x light on

 

This program is incorrect.  

 

1) The "then" clause of program 2 can't work.  Logically speaking, you can not have mutually exclusive commands sent to the same device simultaneously.  Even if you could send them, what result could you expect?  It would be like you're a soldier and you have four commanding officers yelling at you opposite commands all at exactly the same time.  What is one to do?  If you separated the commands with "waits", this would allow the the then clause to run . . EXCEPT

2) Program 1 would kill a properly written program 2 (where each then item is separated with a "wait".)  The status change in the device would re-trigger program 1 which would re-start program 2 then clause when the light goes from off to on.  The purpose of two programs is so that program 2 can command program 1 to disable while it is running.  So a program 2 that does not disable program 1 is no different than a single program that puts the "if" and "then" stuff into the same program.

 

Assuming the purpose of the program was to flash a light it would need to be written as follows.

 

Program 1

If

status light x is on

Then

run then program 2

 

Program2

If 

blank

Then

disable program 1

set light x off

wait y seconds

set light x on

wait y seconds

set light x off

wait y seconds

set light x on

enable program 1

 

In short, there is nothing wrong with ISY logic here, the original program is an attempt to execute an illogical programming sequence.

Edited September 26, 2017 by apostolakisl

[G W]

Atomic?

 

Sent from my SM-G955U1 using Tapatalk

[larryllix]

Atomic?

 

Sent from my SM-G955U1 using Tapatalk

Newer usage (slang)  in some English meaning it cannot be broken down any further.

...or maybe cannot be stopped.

Edited September 26, 2017 by larryllix

[G W]

Good grief. No wonder children can't write proper English.

 

<!---

I am an independent contractor.

My statements are my own opinions and do not represent those that hire my services. --->

[Jimbo.Automates]

In programming it means all instructions will run without interruption. https://en.wikipedia.org/wiki/Linearizability

[G W]

I've been writing code for 45 years and never once heard that.

 

<!---

I am an independent contractor.

My statements are my own opinions and do not represent those that hire my services. --->

[Jimbo.Automates]

Its used in DBMS a lot, and is important in multithreaded programs.

 

Sent from my Nexus 6P using Tapatalk

[G W]

Anyway, the answer to the question is, Yes, if the program dies not have an If event and it's called from another program.

 

<!---

I am an independent contractor.

My statements are my own opinions and do not represent those that hire my services. --->

I know the theory. Just NEVER heard anyone call it "atomic."

 

<!---

I am an independent contractor.

My statements are my own opinions and do not represent those that hire my services. --->

[apostolakisl]

Atomic?

 

Sent from my SM-G955U1 using Tapatalk

 

At one point in time, the atom was thought to be the smallest piece of matter with no further possibility of division, and hence it was named from the Greek word for indivisible (atomos).  The word "atom" conjures thoughts of protons, neutrons, and electrons.  But in programming, we are looking at the root meaning, not the common meaning.  Hence, an atomic clause is a clause that runs as an indivisible unit.

 

Another great example is the word "plastic".  Again from the Greek (plastikos), it means "moldable".  The word now conjures thoughts of hydrocarbon derived hunks of stuff that surround us in so many products, but that is not its root meaning.  A common misconception is that plastic surgery somehow involves hunks of plastic when in fact it is surgery that "molds" the shape of tissues.  No pieces of "plastic" involved.

Edited September 26, 2017 by apostolakisl

[stusviews]

This works:

 

test2
If
        Control 'Test / test kpl' is switched On
 
Then
        Run Program 'test3' (Then Path)
 
Else
   - No Actions - (To add one, press 'Action')
 
test3
If
   - No Conditions - (To add one, press 'Schedule' or 'Condition')
 
Then
        Set 'Test / test kpl' Off
        Set 'Test / test kpl' On
        Set 'Test / test kpl' Off
        Set 'Test / test kpl' On
 
Else
   - No Actions - (To add one, press 'Action')

 

If Status is used instead of Control, the the programs run non-stop. Or the last command can be Off.

[apostolakisl]

This works:

 

test2

If

        Control 'Test / test kpl' is switched On

 

Then

        Run Program 'test3' (Then Path)

 

Else

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

 

test3

If

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

 

Then

        Set 'Test / test kpl' Off

        Set 'Test / test kpl' On

        Set 'Test / test kpl' Off

        Set 'Test / test kpl' On

 

Else

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

 

If Status is used instead of Control, the the programs run non-stop. Or the last command can be Off.

 

There was no reason to make this two programs.

 

But, by "works", I don't know what you mean.  The KPL light does what?

[stusviews]

I'm just using the KPL main button as a test. There's no load. If there were then the load would turn on and off as directed. I already indicated in post #9 that the original program works. The program you referred to was in response to your statement. as follows:

 

This program is incorrect.  

 

1) The "then" clause of program 2 can't work.

[apostolakisl]

I stand corrected, the program does flash the light, though not necessarily every time both flashes.  

 

1) It works the same with status and control as would be expected under the "atomic" nature of ISY and the lack of any wait or repeat.

2) The program summary page indicates that the program ran in less than 1 second and indeed ends prior to the light flashing even the first time.  This is consistent with the atomic nature of ISY "then clause" and no waits written into the program.  ISY must hold the Insteon commands in a separate que.  I don't know what the que limit would be.  I also don't know if the failure of 2 flashes every time is because of out of order commands or failure of the rapid fire Insteon commands.  Again, ISY does not gaurantee that commands in a then/else are executed in the order written in the absence of a wait.  This is per LeeG from ages ago and then confirmed by me running some math equations where order of operations affected the answer.  Usually it ended up top to bottom, but not always.

3) Making it into two programs does not serve any purpose, though it doesn't prevent it from working (I ran it as one program).

[G W]

At one point in time, the atom was thought to be the smallest piece of matter with no further possibility of division, and hence it was named from the Greek word for indivisible (atomos). The word "atom" conjures thoughts of protons, neutrons, and electrons. But in programming, we are looking at the root meaning, not the common meaning. Hence, an atomic clause is a clause that runs as an indivisible unit.

 

Another great example is the word "plastic". Again from the Greek (plastikos), it means "moldable". The word now conjures thoughts of hydrocarbon derived hunks of stuff that surround us in so many products, but that is not its root meaning. A common misconception is that plastic surgery somehow involves hunks of plastic when in fact it is surgery that "molds" the shape of tissues. No pieces of "plastic" involved.

See my post directly above your post.

 

<!---

I am an independent contractor.

My statements are my own opinions and do not represent those that hire my services. --->

[Tapatalk]

This program is incorrect.

 

1) The "then" clause of program 2 can't work. Logically speaking, you can not have mutually exclusive commands sent to the same device simultaneously. Even if you could send them, what result could you expect? It would be like you're a soldier and you have four commanding officers yelling at you opposite commands all at exactly the same time. What is one to do? If you separated the commands with "waits", this would allow the the then clause to run . . EXCEPT

2) Program 1 would kill a properly written program 2 (where each then item is separated with a "wait".) The status change in the device would re-trigger program 1 which would re-start program 2 then clause when the light goes from off to on. The purpose of two programs is so that program 2 can command program 1 to disable while it is running. So a program 2 that does not disable program 1 is no different than a single program that puts the "if" and "then" stuff into the same program.

 

Assuming the purpose of the program was to flash a light it would need to be written as follows.

 

Program 1

If

status light x is on

Then

run then program 2

 

Program2

If

blank

Then

disable program 1

set light x off

wait y seconds

set light x on

wait y seconds

set light x off

wait y seconds

set light x on

enable program 1

 

In short, there is nothing wrong with ISY logic here, the original program is an attempt to execute an illogical programming sequence.

I'm from tapatalk, test for quote edit. Sorry, admin could delete my post.

 

Sent from my Redmi 4X using Tapatalk

Edited October 11, 2017 by Tapatalk