Unity3D and C# - Coroutines vs threading

Question

I'm developing a terrain generation system. The terrain is split up into smaller chunks which can be loaded and deloaded.

The problem is that the generation of the chunks can be a bit on the heavy side.

This can cause small noticeable lags as you walk around.

My first thought was to add threading support by doing all heavy calculations in a thread

(Since I know the Unity3D API is not thread-safe I kept all Unity related objects and calls out of the threading).

Problem is I can't find any way to invoke the thread method back to the main thread of Unity.

My second option it seems is to look into coroutines. From what I understand coroutines allows you to break from a method and return at a later frame to finish it.

(But would coroutines actually be effective for my situation then? For example, if I split the generation method up into 4 frames, would users with fast computers will be punished if their CPU's could have squeezed more per frame, or have I misunderstood something?)

I would love to hear your suggestions.

Answer 1

That's quite simple ;) You should use a class which represents a threading job. This class will be initialized by the Unity main thread. Then you start a worker thread on a function of that class and let it do it's job.

Here's the important part: Of course you store this job somewhere on the Unity side and have the Update loop (or a coroutine) continously checking an "isDone" variable in your class which will be set by the worker thread when it's finished and when it stored all data it produced. It's important that you make the access to this isDone boolean thread safe since both threads will need to access it.

edit

I just took a closer look at my first (untested) example. Unfortunately you can't use lock on value types like a bool, so you need any kind of reference type as lock handle. I've made a small "framework" for a threaded job:

 public class ThreadedJob
 {
     private bool m_IsDone = false;
     private object m_Handle = new object();
     private System.Threading.Thread m_Thread = null;
     public bool IsDone
     {
         get
         {
             bool tmp;
             lock (m_Handle)
             {
                 tmp = m_IsDone;
             }
             return tmp;
         }
         set
         {
             lock (m_Handle)
             {
                 m_IsDone = value;
             }
         }
     }
 
     public virtual void Start()
     {
         m_Thread = new System.Threading.Thread(Run);
         m_Thread.Start();
     }
     public virtual void Abort()
     {
         m_Thread.Abort();
     }
 
     protected virtual void ThreadFunction() { }
 
     protected virtual void OnFinished() { }
 
     public virtual bool Update()
     {
         if (IsDone)
         {
             OnFinished();
             return true;
         }
         return false;
     }
     public IEnumerator WaitFor()
     {
         while(!Update())
         {
             yield return null;
         }
     }
     private void Run()
     {
         ThreadFunction();
         IsDone = true;
     }
 }

This would serve as base class. Just create a concrete Job class which overrides the ThreadFunction function and implement your code. Here's an example:

 public class Job : ThreadedJob
 {
     public Vector3[] InData;  // arbitary job data
     public Vector3[] OutData; // arbitary job data
 
     protected override void ThreadFunction()
     {
         // Do your threaded task. DON'T use the Unity API here
         for (int i = 0; i < 100000000; i++)
         {
             OutData[i % OutData.Length] += InData[(i+1) % InData.Length];
         }
     }
     protected override void OnFinished()
     {
         // This is executed by the Unity main thread when the job is finished
         for (int i = 0; i < InData.Length; i++)
         {
             Debug.Log("Results(" + i + "): " + InData[i]);
         }
     }
 }

This is how you would use the job class:

 Job myJob;
 void Start ()
 {
     myJob = new Job();
     myJob.InData = new Vector3[10];

     myJob.Start(); // Don't touch any data in the job class after you called Start until IsDone is true.
 }

 void Update()
 {
     if (myJob != null)
     {
         if (myJob.Update())
         {
             // Alternative to the OnFinished callback
             myJob = null;
         }
     }
 }

edit
I just added the WaitFor coroutine which allows you to easily wait in a coroutine for the thread to finish. Just use

 yield return StartCoroutine(myJob.WaitFor());

inside another coroutine. This can be used instead of calling Update manually each frame.

Answer 2

Answer by Eric5h5 · Nov 30, 2012 at 08:16 PM

Coroutines aren't really appropriate for this. Everything is still run in the main thread in that case, and there's no effective way of distributing CPU usage, which is especially important considering that nearly everything these days has at least two CPU cores.

Comments Locked · Show 3 · Share

$$anonymous$$ · Nov 30, 2012 at 08:18 PM 0

Share

I see :) Well coroutines are off the list then. I think it is generally kind of odd that Unity3D as the commercial engine it is does not make a (what in some cases) vital feature such as threading easily integrate into the engine, such a shame.

Fattie $$anonymous$$ · Feb 27, 2016 at 04:13 PM 0

Share

How much easier did you want it to be? All the code is above. All threaded program$$anonymous$$g is incredibly difficult, on all platforms and environments.

derekguenther · Mar 28, 2015 at 05:31 PM 0

Share

I know this is old, but thought I would ask in case Eric5h5 is still around - I think coroutines would work fine if your ONLY goal is to reduce hiccups in performance. Threading is probably the better choice because otherwise it will actually increase performance (your main game runs on the main thread, and the new stuff is built concurrently, as opposed to using the main thread to build the new stuff); otherwise, a coroutine which builds the new terrain but yields based on how much time has passed in the frame could also reduce the hiccups, could it not? A potential pitfall is that if your game is experiencing low FPS your new terrain might not be built in a timely fashion, but if you're having performance trouble you will need the extra performance from multithreading anyway. As long as your FPS is decent, coroutines actually ARE an effective way of distributing CPU usage.

Answer 3

Answer by petersvp · Apr 23, 2015 at 01:38 PM

Let me ad my two cents as well. I am also making Minecraft-inspired voxel game but with smooth terrain. After various bench, I ended up implementing my entire voxels stuff directly in C++ with PolyVox, as a DLL. This way, the generation is lighting fast. C++'s DLL uses worker threads, the Boss-and-Employees pattern styles. It exposes C functions so Unity can request loading/unloading of chunks, checking for results and fetching meshes. A C# coroutine constantly polls the C++ library for "Job Results" each frame. If there is a mesh generated, this coroutine "imports" the mesh. The process is not so complicated, the threading model was more chalenging than sending of the meshes to Unity. I basically create byte array with vertex, index and splatting buffers, then in Unity generate the mesh and splatting maps.

Comments Locked · Show 1 · Share

Gaviali · Sep 16, 2015 at 09:18 AM 0

Share

Do you think the speed-up was due to heavy calculations made in C++ (PolyVox) or did the threading model itself also contribute? I'm asking because I'm looking for an alternative to TLP Dataflow that requires .NET 4.5 (Unity is .NET 3.5) and was thinking to implement an multi-threaded actor library myself in C++. But I don't know if it's worth the effort in comparison with implementing the actor model using System.Threading in C#.

Answer 4

Answer by GGeff · Feb 16, 2016 at 01:12 PM

Can use a volatile IsDone rather than locking for efficiency.

Comments Locked · Show 3 · Share

Gru · Sep 01, 2016 at 05:19 PM 1

Share

I would never recommend such a thing.

Reasons outlined here: http://www.albahari.com/threading/part4.aspx#_The_volatile_keyword

and here: http://stackoverflow.com/questions/154551/volatile-vs-interlocked-vs-lock

It's way too risky, you have to remember never to do read-modify-write on the writer thread. Ins$$anonymous$$d, for such micro-efficiency it would be better to use Interlocked. https://msdn.microsoft.com/en-us/library/system.threading.interlocked(v=vs.110).aspx

GGeff Gru · Sep 04, 2016 at 03:00 AM 0

Share

You bring up a very good point - that volatile is no multi-threaded panacea. However, in this particular case I am suggesting removing entirely the getter and setter, and making a simple bool volatile. There won't ever be a chance in this application for a read-modify-write. The bool isDone is only ever read in one thread and written (with no read or modify) in another thread, so it should be quite safe if I've read your links properly.

Gru GGeff · Sep 04, 2016 at 09:32 AM 1

Share

I agree this case seems like one of those where using volatile would be justified.

Researching recently into this topic myself, I've found some confusion and misunderstanding about the true value of using it, even outside Unity circles. I wanted to post the links above to make sure people don't take it lightly and compile a solid reference about it.

While it's certainly a viable option, I would rather recommend using Interlocked like in $$anonymous$$SDN example above - seems more resistant to code change, that's all.

Unity3D and C# - Coroutines vs threading

4 Replies

Follow this Question

Related Questions