# Understanding Synchronization and Data Access with system.util.getGlobals **URL:** \ **Category:** Ignition\ **Tags:** ignition81, scripting\ **Created:** [February 20, 2024, 2:44pm UTC](https://forum.inductiveautomation.com/t/understanding-synchronization-and-data-access-with-system-util-getglobals/86019 "2024-02-20T14:44:55Z")\ **Posts on this page:** 1\ **Showing post:** 3
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [February 20, 2024, 2:54pm UTC](https://forum.inductiveautomation.com/t/understanding-synchronization-and-data-access-with-system-util-getglobals/86019/3 "2024-02-20T14:54:50Z")
1. No. Jython collections, sets, and dictionaries are all based on java "Concurrent" underlying classes, so they are thread-safe, but algorithms built with them are not. 2. Yes. Java is highly multithreaded, so any thread waiting on a mutex could block actions that do not expect to wait (like the tag event thread pool). 3. Not in and of itself, no. 4. (Yeah, you didn't have "4".) The object returned from `system.util.getGlobals()` also holds top-level variables in gateway events. Yes, shared across the entire gateway. Access to those was/is part of its design. I created alternatives (now `system.util.globalVarMap()` in my Integration Toolkit) to avoid this particular complication. (There used to be more problems.) Careful use of `.setdefault` on Jython dictionaries, and `.putIfAbsent()` on `ConcurrentHashMap`s can reduce the need for mutexes or other locks. Consider this topic: > [@Using system.util.getGlobals with classes](https://forum.inductiveautomation.com/t/using-system-util-getglobals-with-classes/78760/20): > > So, I was nerd-sniped pretty intensely by this yesterday, as the nesting of persistent dictionaries has some performance considerations that suggest some instance caching is appropriate. This is utterly untested, but should give you a framework to use if you decide you really don't want the latency of database storage (and I wouldn't use document tags): from threading import RLock \_g = system.util.getGlobals() # This class requires a dictionary in its constructor to # carry state. It delega… Related: If you always use one-liners in your gateway events that delegate to project library scripts, then you aren't creating any top-level variables that could clash with other residents of `system.util.getGlobals()`. --- _[View the full topic](https://forum.inductiveautomation.com/t/understanding-synchronization-and-data-access-with-system-util-getglobals/86019)._