This same script will be used by ~40 other tags; you see how there can be a concurrency problem here?
Now I don't know exactly how the gateway processes these scripts, but there is a very slim (yet non-zero) chance that two tags get "true" at the same time and somehow the scripts run at the exact microsecond which means that only one of the two rows will actually get appended to the dataset in ActiveCalls tag.
Is this concern real?
I read in this neat post that a Gateway Event "Tag Change" script has an unbounded queue that holds and executes each tag's script individually. And "queue" implies they would run serially, avoiding risk of deadlocks. Is that correct? And would that address my 1st concern, if true?
Not only is the valueChange script queue bounded to 5 per tag, but there is also a bounded thread pool, such that only 3 scripts can run at one time. This adds to the possibility of queue sizes building up and eventually discarding events that are pushed out of the queue.
valueChange events should never run long running tasks, and should not run longer latency tasks such as interfacing with databases.
Yes, to an extent, each event in the queue is executed in order prior to the next event being processed, for all tags assigned to that Gateway Tag Change Event. You can split different changes across multiple threads (allowing asynchronous execution) by defining multiple change events. So in this case you will want to author your script to be generic and assign all tags to that event.
For reference:
I would also recommend that you look into the initialChange flag.
Thank you, Louis.
That gives me one more reason to avoid "Value Changed" events (besides the fact that maintainability would be a nightmare for 40+ copies of the same script, that is if I don't use a project library function).
So in this case you will want to author your script to be generic and assign all tags to that event.
Exactly, my code will of course be generic if consolidating all events into one "Tag Change" definition addresses the (very unlikely) race condition I'm concerned about.
Yes, to an extent, each event in the queue is executed in order prior to the next event being processed, for all tags assigned to that Gateway Tag Change Event.
"to an extent" did confuse me a little here but it seems like the answer is a clear "yes" if all my tag paths are in one tag change definition on the gateway? Because that is exactly what I want here.
And no, I don't want any parallel or asynchronous execution. It would be overkill/overengineering for a 1-4 ms code.
Yeah, that is what I was attempting to point at. As well as the fact that not all Gateway Events handle threads in the same way.
You should use a project library function for this, particularly in a Gateway Tag Change event, as there are some legacy scoping issues that you should avoid, and the library function accomplishes this.
For valueChange scripts, you should do this also, but the script has to be located in the Gateway Scripting Project.
