- Unity has a functionality called Coroutines that can be a substitution for Threads in some cases.
Why create threads when there are coroutines?
Coroutines have nothing to do with Threads. Coroutine methods can be executed piece by piece over time, but all processes are still done by a single main Thread. If a Coroutine attempts to execute time-consuming operation, the whole application freezes for the time being.
Threads are different. The execution of separate Threads is managed by the operating system (this actually depends on the .NET implementation). If you have more than one logical CPU, many threads are executed on different CPUs. Thanks to that, any expensive operation will not freeze your game, but it might slow it down a little.
When Threads are suboptimal, Coroutines may be preferable:
Creating a Thread is an expensive operation. If you use a Thread polling design pattern, you have to synchronize your computed data to the main thread. This is a very individual thing, so you have to consider this very carefully. It may even be necessary to perform some performance tests, because synchronization might be more expensive operation than computing your data in the main thread in the first place.
- Network communication
- Files operations
here in this article the threads and the issues arising from the application of threading and synchronization has been dealt with clearly in the article, still many points are missing related to the coroutines which is the subject line. Still very very useful article.
Threads were not supported in Unity WebGL until 2019.1, and I'm not sure if that actually supports .NET threads. So that might also be a suggestion to use coroutines instead of threads.
I've noticed that threads have different limitations on different platforms, i.e. the maximum number of threads differ on iOS compared to PC and MacOS, so its best to keep threads to a minimum.
The thread implementation does not seem stable under stress (Network, CPU and memory), particularly under iOS where iOS sometimes simply terminates the app if thread activity is high. It could also be related to a memory leak, resource hogging or something like that. After several hours of use, an iOS threaded app may tank with no warning.
Using .NET networking with threads work alright for light network requests, but it seems that using the Unity networking API (WWW, etc..) may be a better option.
I think calling any feature "Dangerous" will shy new users away from using it.
Threads are not dangerous. Using them will not damage your computer.
Threads are unpredictable when improperly implemented and being able to adequately convey that to new and intermediate users is necessary.
Please sign in to leave a comment.