<div dir="ltr"><div>I seem to recall some discussion on thread safety in the engine, specifically in the context of, "There is none". Is that true?</div><div><br></div><div>I was writing some multi-threaded code that was behaving oddly around the VerseKey class and I couldn't at first figure out why my tests were failing intermittently. All I was doing was instantiating a VerseKey, setting its text, and then reading the parsed values in each test function. I eventually tracked it down to a race condition in the VersificationManager::getSystemVersificationManager() factory method.</div><div><br></div><div>The briefest glance at the code shows that it has no thread safety in constructing the manager and applying it to the global instance. That alone was enough to cause the intermittent failures. My testing showed it clearly was a threading race condition, as it would seemingly appear at random throughout the code - sometimes manifesting as just a null pointer reference, sometimes as an allocation issue, and sometimes even as a UTF-8 encoding issue for the text I was passing in!</div><div><br></div><div>So the question: is this intentional? Do we have a solution for thread safety in the engine, or do we simply not offer any guarantee of thread safety? I know Troy has mentioned that SWMgr is not thread safe, and he will often have 3 instances of it for doing different tasks. However, even if that approach was taken, they three would share the state of this one static global. In an application, the solution here would be to just pre-emptively call getSystemVersificationMgr before any other code might access the VerseKey class. However, in my case, the code was all running in a test suite that did not offer a solution to ordering the code and ensuring some setup code was executed first.</div><div><br></div><div>For now my solution is just to disable parallel test running, but I wanted to see if this acceptable thread safety, or if this is a place where thread safety was unintentionally being violated.</div><div><br></div><div>--Greg</div></div>