koobas.hobune.stream
Are global variables thread safe?
Are global variables thread safe?
I have a global 2D array that keeps track of what tiles of the game are occupied. Many different scripts modify this array. Will I run into any race conditions?
Hello,
Your global variable are not thread safe. But since Unity engine is mono-thread for all the game stuff, you don't need to worry about it.
BUT, if you do your own calculations on a thread different from the main thread, yes, you must be careful and start to lock and put fences everywhere it is required.
Remember only the main thread is allowed to touch Object!
Unity3D methods are not thread-safe. However any 'static' field you make will be thread-safe after you use some of your System.Threading skills.
With this being said, using a static field as a wrapper for a Unity3D method may yield... unexpected results.
'Atomic' means thread safe, see here: https://msdn.microsoft.com/en-us/library/aa691278(v=vs.71).aspx
No they are not. You need to lock the array any time you read/write to it. This should do the trick:
public class TileManager
{
private Tile[] m_Tiles;
public Tile this[int i]
{
get { lock(m_Tiles) { return m_Tiles[i]; } }
set { lock(m_Tiles) { m_Tiles[i] = value; } }
}
}
You also need to make sure you do not try to assign to the private array without a lock statement. Note that the getter does not lock the actual Tile object, only the array, so any operations on the Tile object will not be safe unless you lock it.
To address the problem mentioned in the comment below - if you are not creating your own threads, then you are safe and do not need to do any of this. Without concurrency there are not race conditions.
He is talking about scripts modifying the global array.
Since script are run from the main thread, locking is completely useless. Your advice is dangerous in the way is it a big waste of computation.
As far as I understand, he is not doing any multi-threading things.
If he is not multi-threading, then there are no race conditions - that is just a give in. A script could still create a separate thread to run a method that accesses the global array.
Sorry for the lack of clarity. I was asking about normal usage (since Unity uses multithreading internally). I am not creating any threads myself.
So to clarify, with normal usage I won't have any issues with race conditions when modifying global variables? What about if the modification is in a coroutine?
As far as any code you write is concerned, Unity is not multi-threaded. It might be internally, but they have protected your code to the point that you do not need to worry about threading at all.
So, in short, you do not have to worry about race conditions, even if you are using coroutines.
Unity is multi-threaded.
Not the game loop, which is run on the main thread only. They never put any protection since it is not intended to be run on other threads.
And as jdean300 said, coroutine is safe to use (Not thread-safe!).
Look at this asset, it uses coroutine, but in other threads. If you look carefully, there is methods to switch from the main thread and others. https://www.assetstore.unity3d.com/en/#!/content/15717
