Threading in Unity

I’ve done some searching on this board and never really found any posts that answer my question.

I’ve also looked up the unity script reference for coroutine and yield. I don’t fully get what they do based on that description.

Here’s my scenario:

I’m creating a piece of training software for disassembling/reassembling/describing parts of guns and other equipment.

Right now the feature I’m implementing is a second camera pointing away from where the main action is going on, when a component is clicked I instantiate a clone in front of that camera. This second camera is displayed in the upper left corner of the screen. The component display is rotatable by the user and information about the piece is displayed.

HOWEVER, since I’m instantiating clones, some of the components have somewhat complicated geometry and take a little time to load which in turn freezes the whole program until the object is instantiated.

I want to do these instantiations in a separate thread and display “loading” text in the smaller camera window so that only that feature is out of commission while the instantiation is happening.

In other programming environments I know how to manage threads. In unity, I do not.

Are coroutines the unity word for threads? Are they different? Should I use a thread or coroutine? Can someone show me an example or two?

Your help is much appreciated : ]

Ok just to sum it up again because it seems Eric’s answer wasn’t enough (but it actually should :wink: ):

  • Unity’s Api is NOT thread safe so it can’t be used from another thread. Unity have also implemented a thread-check to prevent you from trying to use it from another thread :smiley:
  • The scripting environment is just plain and simple .NET / Mono so if you really want to start a new thread, read into the C# docs.
  • You can use your own threads for calculating something in the background or communicate with a native code plugin but not to interact with Unity.
  • Coroutines implement an cooperative multitasking system and they aren’t invented by Unity. Unity uses .NET / Mono Generators to implement them. If you’re interested in how they work see this post.
  • As already mentioned Instantiate is an atomic operation (can’t be divided into smaller parts) so it runs until it’s done. If it loads a really huge thing there’s no way to speed it up.
  • If you have Unity pro you could place the stuff you need into a seperate scene and load this with Unity’s own background loading thread by using Application.LoadLevelAdditiveAsync. This allows you to load it in the background, but it’s much slower than the straight-forward functions because it’s designed to keep the framerate at an acceptable level.

Coroutines are not threads; the Unity API isn’t thread-safe and can’t be used in threads. Instantiate is an atomic operation and not something that takes place over a number of frames, and as mentioned can’t be put into a thread. You can still use a coroutine for loading text, though you won’t be able to get around the freeze with this:

function InstantiateWithMessage (go : GameObject, message : String) {
	guiText.enabled = true;
	guiText.text = message;
	yield;
	Instantiate(go);
	guiText.enabled = false;
}

That would assume the script is attached to a GUIText object. The text is enabled, it waits a frame to make sure it’s visible, then it instantiates the object and disables the text the next frame, so the text is visible for however long that particular frame takes.

An alternative would be to instantiate the objects ahead of time and disable them immediately, then re-enable them later when you want to “instantiate” them. This would probably eliminate most of the freezing, though there’s still the possible issue of large textures being uploaded to the graphics card when the object is made visible for the first time.

Thanks for this a great and well-written page on multithreading.
this is an example of multithreading in UnityScript:

function Start() {
    var thread = System.Threading.Thread(doLogic);
    thread.Start();
}

function doLogic() {
     // do stuff in here
}

in unity the best practice is to load any large models at start, but leave them somewhere in outer space of your game out of view, like that they are in memory and labelled textured etc, and then when you need them simply change their position.

In our games; we generally calculate time consuming calculation in a different thread. The non ui thread sets a boolean so that ui thread can pick up the results. Here is how we do it.

Coroutines are a way to describe a piece of logic across multiple frames in one continuous block of code, without having to resort to multiple small methods and state variables managed across frame calls.

i.e instead of:

public void Update()
{
    switch (state)
    {
        case 1: DoSomething1(); break;
        case 2: DoSomething2(); break;
        case 3: DoSomething2(); break;
    }
}

private void DoSomething1()
{
    ...
    state = 2;
    state1FinishTime = Time.time;
}

private void DoSomething2()
{
    if (Time.time - state1FinishTime > 2)
    {
        ...
        state = 3;
    }
}

private void DoSomething3()
{
    ...
    state = 0;
}

You can write:

public void Update()
{
    Start(DoSomething());
}

private IEnumerator<YieldInstruction>()
{
    ... // DoSomething1()'s code
    yield return WaitForSeconds(2)
    ... // DoSomething2()'s code
    yield return null;
    ... // DoSomething3()'s code
}

In other words Coroutines are only a more readable and maintainable way to write certain things, they are not meant to (and can’t) be used to perform expensive operations in the background.

Threads with callback (Inspired from the Java world)

Class that can accept any type.

public class ResultCallbak<T> {

	public Action<T> success;
	public Action<String> failed;

	public ResultCallbak (Action<T> success, Action<String> failed) {
		this.success = success;
		this.failed = failed;
	}
}

Example of usage

   Thread parseJsonThread = new Thread(SomeFunctionOrMethod(someArgument, new ResultCallbak<ReturnObjectAnyType>( 
        successObjectOfTypeReturnObject => Debug.Log(successObjectOfTypeReturnObject.name), //Success
        failedString => Debug.Log(failedString) // Failed
    )));
    parseJsonThread.Start();