Questions regarding preventing multiple instances of a single rule from running simultaneously come up often, with a variety of solutions (private boolean, local variable, global variable, express the logic within a driver, etc).
An enhancement to RM to have a property for each rule to allow/prohibit multiple instances of the rule from running simultaneously, with the property enabled/disabled as a checkbox for the rule (ie., without requiring each user to express their own method for this mutex control) would significantly help many users.
The problem with this is that there is no single meaning possible for single instance. I will look at it, but I'm not optimistic. Waits, Delays, running other rules all come into play. That's the reason we have made it straight forward to do this using a Required Expression and Private Boolean, or a Conditional Trigger and Private Boolean, so that you can choose what it means precisely. I'm not at all sure there is a one-size fits all way to do this.
The idea of "single meaning possible for single instance" seems pretty clear to me:
at the moment that a rule is triggered, does there exist a running instance of that same rule, or not?
From an end-users perspective, the existence of the other rule is separate from of the state of the other instance, ie. whether a step within the rule is waiting, delayed, etc.
Of course, I don't know how that's managed within HE, whether (for example), the rule is not "running" (and does not "exist") when the current action within the rule is "delay" (perhaps there's an HE-wide table of delay timers, and as they finish each rule is run again, resuming at the statement following the delay).
The concept of a rule "running" is not something so cut and dried as you make it out to be. There is no way for an app, a rule, to determine if there are "other instances" of it running; this is inherently ambiguous to the rule.
The path of a possible solution would be for a rule with 'single instance' selected to set a state object when it is triggered, and then not allow further triggers to occur until the rule "exits". For a class of simple rules this could be straight-forward: clear the state object setting after the last action of the rule runs. However, not all rules fall into this simple class, and it these more complex rules that I'm worried about. I will think about it.
In the meantime, there are simple well documented ways to do this.
It would not solve the problem of multiple simultaneous instances, because this problem primarily arises when there are embedded Delays in Conditional Actions. When there is a Delay, or a Wait, the rule exits -- there is no longer a thread. But during that time another trigger event can occur, creating a new instance of the app, which at that instant is but a single thread. Bang, rule blows up because there are now two simultaneous instances of it running. The stack maintained for IF-THEN-ELSE in state, of which there is only one, will no longer work right, and a multiple simultaneous instance error will occur.
Rules have state, and there is only a single copy of state for an app. So to the extent the rule relies on state for anything, a second simultaneous instance is going to blow up.
Rules without embedded delays in conditional actions can usually withstand multiple triggering, multiple simultaneous instances. They may bang away at turning on a switch or something, but usually this is harmless.
