Should the system.tag.writeAsync function always/generally be preferred over the system.tag.writeBlocking function when doing a scripted tag write and the remaining script execution does not read or otherwise depend on that tag?
Early on in my Ignition learning I just defaulted to using the system.tag.writeBlocking function in almost all cases, as the examples in the Ignition documentation seem to use that exclusively.
I suspect it would be better to use the system.tag.writeAsync function when performing a large tag write (many tags at once) but when performing one, or a few, tag writes at once might it be more performant to use the system.tag.writeBlocking function and avoid the overhead of spawning new asynchronous threads?
Known exceptions:
- When writing to the same tag multiple times and each write should be processed in a given order (e.g. for tag history).
Typically I use writeblocking in operations that users would expect a slight delay. Buttons, etc...where bindings aren't possible. An async script might show that something is written but isn't actually to the operator.
Tag Scripts, Tag Event Scripts, anywhere a thread lock isn't desired, etc.. we attempt to exclusively utilize async writes.
I don't believe that writeBlocking multiple tags vs writeAsync will have any difference in backend performance. However, blocking locks the thread while the writes are being done. Which could in some places cause issues, and in other places will cause issues.
Neither writeAsync on the client/designer nor the gateway generates asynchronous threads directly - they recycle threads from an internal pool.
In general though, the overhead of successive network operations dwarfs the overhead of thread creation, so the most important thing is to batch your read and write calls together. There's plenty of other advice about when to avoid blocking in particular as well, and in general if you don't actually need a return code or to block execution, sure, go with writeAsync by default.
3 Likes