This object is in archive! 

Rule execution semantics

David shared this question 8 years ago
Need Answer

Can more and one rule execute at the same time?


If not; what about long running rules, will they temporarily halt the rule engine?


If they can, are variables safe to use across rules (~thread safe in programs)?

Replies (4)

photo
1

David,

Rules seem to execute simultaneously. If you have a very long WAIT in one rule, it will not stop other rules from being executed.

Variables seem to be global, i.e. contents can be set in one rule and read or manipulated in another.

Brgds

Robert

photo
1

Hi Robert,

Okey a follow-up question, when you say simultaneously, is in your opinion it only during WAIT other rules can execute. If it is, variables should be safe to use for mutual exclusion? Thus I can create two rules that do something similar to this:

Rule 1


    WHEN switch1 is pressed

    | JOIN

    | IF sync_var = 0 OR sync_var = 1

    | | sync_var = 1

    | | DO_ACTION

    | | WAIT 10 sec

    | | sync_var = 0


Rule 2


    WHEN switch2 is pressed

    | JOIN

    | IF sync_var = 0 OR sync_var = 2

    | | sync_var = 2

    | | DO_ACTION

    | | WAIT 10 sec

    | | sync_var = 0


If rules can execute at the same time the IF and the setting of the sync_var can give a race.

This is for question https://community.zipato.com/topic/control-all-lights-from-all-switches where I think I need some "settling time" (the WAIT in the rules) and I just want one of three rules to execute at the same time.

photo
photo
1

David,

I have just tested, and can confirm that variables are NOT thread safe (or Rule safe).

A variable accessed at one point inside a rule, can be changed by another rule, before the rule has completed its execution.

The enclosed two rules will demonstrate this quite well: Each of the rules have a Scheduler. The first rule is set to execute every minute, the second will execute every five minutes. The SEND actions simply send messages. If you have PRO, the messages can also include the contents of the variables.

The FiveMinuteRule store the value of a variable which is incremented every minute in the OneMinuteRule, into another variable, then the rule waits for 4 minute, then compare the contents of the variable with the variable holding its initial contents.


The variable will have been changed every minute by the OneMinuteRule, and will be different when tested the second time inside the rule.

photo
1

Hi Robert, thanks, I now have a better understanding how the rule executor works. My assumption now is only one rule execute at the same time (other rules may not have started executing or they are in WAIT state).


I would then propose another example; two or more rules rules that all executes every minute and runs the same block of code:


  1. x = x + 1
  2. x = x + 1
  3. if x is not even send message


If ever the message is set we know that another rule slipped in between the executions of this rule telling us that two rules might execute at the same time even if not in WAIT state.


I really hope that is only during WAIT operations that other rules may execute.

photo
1

Even simpler rules:


  1. x = 0
  2. repeat 100 times, x = x + 1
  3. if x != 100, send message

photo
1

David,

I have not yet tested for documentation, but my impression is that the execution of one rule does not case execution of other rules to wait for anything, thus the reason for the need of the JOIN command.

I believe that the event queue is handled in a FIFO order, as fast as the CPU and on-board software can handle them. If a RULE started as a result of an event takes time to complete, i.e. because the action involves DNS lookup and getting HTTP results, other events are handled simoultaneously.

photo
1

Yes, but JOIN could have been something that had to do with WAIT...

But now I tried it, I created two rules, both executing every minute, just counting the same variable up 1000 and 1001 times. (Attached, please check if I did something bad, tried it with the JOIN statement too, just to be sure that that special thing didn't pause the rest of the rules..)

I don't have the pro version so I cannot check what the variable ends up being but it isn't correct anyways... so the executions are interleaved. (If I just leave one rule running I don't get any errors.)

I'm thinking that they have implemented this using java threads. Makes sense to run a few in parallel.

photo
photo
1

I think rules cannot simultaneously run, this is not a multicore processor that can run different tasks (with different core) at the same time. In my opinion the processor runs one rule after another as fast as it can, WAIT and REPEAT puzzles don't "trap" processor execution, in my opinion they continue processing other rules until the Timer or the Counter is done. I created a rule to show the secuencial process of the rules, I guess the rules run based on the number of rule, i. e. Rule 1, Rule 2, Rule 3, etc.


First image shows the rules I created as a "timestamp" demonstration of when the rule runs. On the second image you can see VAR1 has a smaller value than VAR2, since I created and saved VAR1 rule first and then second. Then I moved VAR2 rule on top of VAR1 rule, syncronized rules, and then run again and now VAR2 has a smaller value than VAR1, third image.

photo
1

I just checked, they do run in parallel. Check Robert's second comment thread above.

photo
1

If this processor was able to run simultaneously then the timestamps on my example should be identical. I just proved that just changing the order on the rules changes the timestamp accordingly which proves the sequential processing. Only multicore processors can run "simultaneously".

photo
1

Alberto,

I am quite sure the Event Queue is sequental, but that the rules are executed non-blocking in parallel. I guess you can test this by having two rules triggered by the same event (e.g. two rules for the same switch), then saving the StartTime and EndTime of each in separate variables, and having a repeat 10.000 or something which takes a bit to complete...

photo
1

Alberto,

I am quite sure the Event Queue is sequental, but that the rules are executed non-blocking in parallel. I guess you can test this by having two rules triggered by the same event (e.g. two rules for the same switch), then saving the StartTime and EndTime of each in separate variables, and having a repeat 10.000 or something which takes a bit to complete...

photo
1

That is what I meant with "don't trap", every processor has a watchdog fuction which monitors the time of execution of the processor and faults the processor if it's too long. WAIT and REPEAT commands do not "trap" the processor until they finish, the processor keeps running all rules and executes when timer or counter is done, although I wouldn't say in "parallel" you need multicore processors in order to run different pieces of code in parallel. With your rules you prove only that two rules can affect the same variable while they run, even though one of them is not "done" running, this doesn't mean they run in parallel, they just run very fast one after the other... to us looks almost "at the same time".

photo
1

>> to us looks almost "at the same time".

-And I'm fine with that :-)

photo
photo
1

Although not on true parallel, things can be executed in semi-parallel in single core processors by using threads. This is probably what happens here. Each rule executed in their own thread and appears to run in parallel.

Leave a Comment
 
Attach a file