koobas.hobune.stream
Can I use Unity math function in other threads?
I've read that Unity is not thread safe and I can only call Unity API in main thread. I'm trying to use multi-threading mainly for pure math calculation such as vector manipulation or something like that. I want to ask that can I use Unity basic math function in other thread such as vector magnitude, square root, dot/cross product etc? Or do I need to code those calculation functions too?
As far as I have heard, the official line is that the whole Unity API is not thread safe. Whether this applies to particular aspects such as the Mathf class, I'm not sure.
Personally, I can't see how a static math function which uses only variables defined within its own scope could be thread-unsafe, but that's just speculation without access to the actual source code.
However, since version 2.6, Unity has an assert which checks whether the the non-thread-safe functions are being called from an external thread. So, if you're doing something unsafe, you should get an assert fail in the console, looking something like this:
!Thread::EqualsCurrentThreadID(m_MainThreadID)
If you're not getting that message, you may be safe.
If you are getting the warning, you might want to implement your own thread-safe versions of those particular functions (which are relatively simple, and many examples exist out there which you could copy).
Incidentally, Debug.Log is thread safe (I think this is the only Unity function where this has been specified). So you can still log results from your functions which are running in other threads!
FWIW, the current documentation says nothing about thread safety, and I can't find any page that claims Debug.Log is guaranteed to be safe.
The documentation has changed many times, however Debug.Log always has been thread-safe. That's why we have two different log callbacks Application.log$$anonymous$$essageReceivedThreaded and Application.log$$anonymous$$essageReceived.
Strangely those are currently missing in the member listing of the Application class ^^. They really have some issues with their documentation system.
The $$anonymous$$athf class is completely thread-safe as it's just a wrapper for System.$$anonymous$$ath. $$anonymous$$ost of Unity's built-in value types like Vector2/3/4, $$anonymous$$atrix4x4, Quaternion are also thread-safe.
System.Math is for sure thread-safe, though it doesn't have vector functions.
There isn't any reason for me to believe that the Mathf function isn't thread-safe.
Did you try it? Something like this would be really easy to test, so why not just try it and see if it works instead of asking here? A better question to ask here is what alternatives you could use if it doesn't work.
one of the problems with non-thread safe code is that they can appear to work fine 99% of the time, and it's possible for race-condition bugs can only show up extremely rarely by chance - so in cases like this it's best to know rather than just test :) (That said, I don't know the actual answer to the question!)
Another reason to not trust thread-unsafe code is that it shows different behaviour depending on thread scheduling, the processes that are sharing the cpus and I/O tasks, which usually change from one machine to another. That makes impossible to get reliable testing on a single machine.
Yes you can. What you can't (or shouldn't) do is manipulating the renderstate from a thread, as this probably will crash unity.
