Note, I'm talking about rule-local variables here, not hub-global.
Scenario: a rule (let it be 'rule1') has a STRING variable named tmpTTStext. Two instances of rule1 inadvertently & concurrently fire. If rule1:instance1 sets tmpTTStext to 'fred' and instance2 sets tmpTTStext to 'barney', what should my expectations be as to each instance's perspective on the value of tmpTTStext at the point in time where both have set it?
Note that I'm not referring to the variable being thread-safe in that changes are serialized (and still 'tamper' with one another's respective variable value).
Is the variable's scope local to the instance or to the rule as a whole such that last writer wins or something else?
Hence the need for required expressions, and/or private booleans, to allow some control over concurrency. - Keeping rules short & simple (more smaller rules) helps to allow rule runtimes to be short, given the event driven nature of the system.
Thanks, both--that reflects my experience, too. I've implemented a variety of mutexes in the form of required expressions (using hub-global bools/rule-local bools and/or momentary switches) that kinda-sorta work but I find that the required expression sometimes evaluates to false when it's true (albeit only very recently returned to true per debugging). While I can repro this, it's tough to get the race condition to line up perfectly in test scenarios.
^ this to me requires an architectural re-think wrt/ to var scope since concurrency from multiple triggers is an ever-increasing reality as the devices we use explode and the rules/triggers follow in kind.
Thread-safe doesn't cut it; the only thing that does is instance-safe since concurrency is, IMHO, unavoidable.
Yeah, I've seen required expressions using virtual switches, be "missed" given race conditions as well. My personal "guess" is that some of the "heavy weight" operations (turning on/off a virtual switch) can take enough time to complete, as to not act as the immutable mutex or semaphore, that you think they should be.
I've had better luck (sounds like your doing similar stuff), using global HV bools or PBs - Those seem to be lighter weight in terms of execution time (which sort of makes sense), but yeah, there are still race conditions that can still occur, if you working down in the single msec event trigger range.
Bottom line, don't use Hubitat for hard real-time work or anything involving human safety, it's not a PLC -
Having a named distributed lock manager would be a wonderful thing, IMHO - but there is a reason that VxWorks still exists. Something to work on, when I retire, I guess. - That and active/active failover.
@GuyMan, on the topic of keeping rules short: I'll respectfully disagree but also ack your general architectural points as well as the implicit 'is it ready/really there yet' especially when it comes to commanding physical devices like overhead doors . To further acknowledge your point, I've read before and totally grok the general principles of said guidance but I settled on Hubitat for the very opposite reason... aforementioned richness/extensibility.
Hubitat's architecture is too rich/extensible to ignore--as I said, it's why I have a C8 Pro and 2 x C8s running the house. It's an architecture that by-design allows for and leads to rich/powerful/lengthy rules that cannot reasonably be compartmentalized. For example, centralized TTSspeech/notify/logging APIs (written in RM) and Coherence (dashboard, alarm panels, etc.) rules and presence detection rules and multiple mesh'd hub rules using shared momentary switches/vars, etc.... the list goes on.
While I can make your case, too--platforms as rich as Hubitat appeal--nay beg--to be properly used by folks like us/me because of said richness/extensibility which inevitably leads to powerful (but complex and lengthy) rules/logic/triggers/interactions/dashboards/lighting scenes/button logic/etc.
Again, though--thanks for validating the opening question; much appreciated!
. To further acknowledge your point, I've read before and totally grok the general principles of said guidance but I settled on Hubitat for the very opposite reason... aforementioned richness/extensibility.
