Hi everyone,
I created a tiny script help you write standard Unity co-routines which can run on a background thread as well as access Unity API easily. Any feedback would be great! Thank you!
It’s now free on Asset Store: Thread Ninja - Multithread Coroutine | Tools | Unity Asset Store
Thanks for the release.
Hi, I am trying to load a RevMob banner Ad from the background thread but it doesnt work and crashes the android game… This is how i do it:
private static readonly Dictionary<String, String> REVMOB_APP_IDS = new Dictionary<String, String>() {
{ “Android”, “MYID”},
{ “IOS”, “copy your iOS RevMob Media ID here” }
};
static RevMob revmob;
static RevMobBanner banner;
public void Start ()
{
revmob = RevMob.Start(REVMOB_APP_IDS, “Main Camera”);
}
public void PowerUpsButtonClick ()
{
// other code
StartCoroutine (StartExamples ());
}
IEnumerator StartExamples()
{
Task task;
this.StartCoroutineAsync(Blocking(), out task);
yield return StartCoroutine(task.Wait());
}
IEnumerator Blocking()
{
LogAsync(“Revmob loading banner”);
if( revmob != null) {
banner = revmob.CreateBanner(RevMob.Position.BOTTOM, 0, 0, Screen.width, 170);
}
LogAsync(“Jump to main thread.”);
yield return Ninja.JumpToUnity;
banner.Show ();
}
The game crashes out and I get the error :
10-31 14:51:12.496: E/dalvikvm(10886): JNI ERROR (app bug): accessed stale local reference 0x1d200001 (index 0 in a table of size 0)
10-31 14:51:12.496: E/dalvikvm(10886): VM aborting
10-31 14:51:12.716: E/MP-Decision(2179): num online cores: 2 reqd : 1 available : 4 rq_depth:0.000000 hotplug_avg_load_dw: 26
10-31 14:51:12.716: E/MP-Decision(2179): DOWN cpu:1 core_idx:1 Ns:1.100000 Ts:190 rq:0.000000 seq:197.000000
10-31 14:51:13.377: A/libc(10886): Fatal signal 6 (SIGABRT) at 0x00002a86 (code=-6), thread 12633 (GC_start_routin)
Can you pls help me out on this one ?
Hi, I think it’s just not allowed to do this on another thread, you must change the UI on the main thread. Background thread is usually used for performing heavy computation.
Hi Thanks for ur reply…
Can you please give me an example as to what kinds of things can be performed by this library?
@Karthikrick, let’s say you want to calculate lot of noise function from
http://forum.unity3d.com/threads/68764-LibNoise-Ported-to-Unity
You do something like this
for (int i=0; i<threadCount; i++) {
int min = i * iterations / threadCount;
int max = (1 + i) * iterations / threadCount;
this.StartCoroutineAsync (Compute (min, max));
}
To split Compute amongst threadCount threads.
Where Compute is this call to the beast that is noiselib
IEnumerator Compute (int min, int max)
{
Debug.Log (min + " - " + max);
for (int i=min; i<max; i++) {
perlins [i] = (float)perlin.GetValue (i, 0, 0);
}
computed++;
yield return Ninja.JumpToUnity;
// do some Unity stuff like generate cubes based on noise value
}
Thank you for making this asset, Ciela Spike.This seems very useful and so few have tried it or commented on it.
When I first learned of ‘co routine’ I originally thought they were something like this, ‘co processing’ a routine. Now they actually can and do, improving performance significantly over a regular co routine.
Being able to jump in and out of the main thread is useful. If Unity’s API isn’t thread safe, something like this seems like a nice compromise. I’m actually a little curious as to why Unity itself wouldn’t pursue a similar feature. C# isn’t known for its light speed, multi cores can be very useful, simplifying them and making it as clear as possible when in a backing thread or the main thread seems very intuitive to me and goes well with the idea of more rapid development.
Hi,
First of all thanks a lot for sharing such great tool with us, it’s pretty powerfull 
I’m trying some load tests using your system, and found that over 3 very hungry tasks at the same time cause a huge performance drop in Unity. I suppose it’s related to one of the threads being executed on the same core as Unity’s main thread.
As we know that Unity uses cores 0 & 1 for most of it’s operations, don’t you think it could be usefull to be able to set affinity to the thread pool to avoid those cores ? I made some researchs but didn’t found how to plug it easily in your system. So I really would like to have your opinion on this idea.
Again, Thanks a lot !
Hi! I’m new to unity and programming in general (lone artist/designer), also the idea of threading is completely new to me. So, I’m having a bit of trouble understanding the concept behind the usage of the code (I’ve never used threading before and don’t use coroutines too often)… Could anyone give me a basic explanation about the reason behind the workflow/the logic behind the code? About the background and foreground threads and the kinds of things I’m supposed to do in one but not the other?
I’m sorry if I’m being too silly, but I really want to use this whenever I can but I’m having a hard time understanding when to use it and how to use it properly. But the idea of better performance is just too juicy to pass up. Also, would it be possible to use this with MEC (More effective coroutines)? it sounds like it would be a golden combination (MEC coroutines are twice as fast as unity’s and don’t create any GC).
Anyway, any advice would be greatly appreciated.
@Alverik If bits of your game code does heavy calculation and you don’t want your game framerate to drop or your game to freeze up while that’s happening, you can run that bit of code on a separate thread. Then when you need to access the Unity API (for example to change the position of a gameobject, or refresh an array of particles), you jump to the main thread using yield return JumpToUnity();
MEC is for spawning 1000s of coroutines, usually an indication that you’re doing something wrong. I explain: if you have 1000s of characters doing stuff and display isn’t the bottleneck, it’ll be so hard to debug that you’ll spend most of your time figuring out who does what, coroutines are awful when it comes to debugging. The better alternative is to centralize all your character actions, store states in big arrays and process all that in one loop, handling timing with counters. Added benefit is it’s much much more performant.
Thanks, great info by the way, still haven’t had to control such a huge amount of characters but that’s handy to know. Still, I have a bit more questions. My main confusion is how this is going to be processed. The order. So, If, as I’ve understood, you start in the background thread, which is supposed to be used for heavy calculations, then when I use yield return JumpToUnity() will the next code be done immediately or will the system wait for the previous code to be done to run it? This confuses me because isn’t the whole idea from threading to do two different things at the same time in separate threads? or am I misunderstanding how threading works or is used in unity?..
Again I’m sorry, I’ve only started to learn C# like 3-4 months ago… So I’m still very green… (I did read a book about C once, but that was like 10 years ago…)
Best avoid subjects that are problematic for really experienced programmers then. Stick to main thread. Avoid co-routines. Instead do it normally and directly.
When the game is finished, run the profiler to understand where to optimise. This will be surprising - it will generally be slow where you least expect it, and will be something that co-routines and threading wouldn’t have helped with anyway. Those things seldom help unless people know precisely what their program’s pressure points are.
-Like Hippo says-
Ill answer anyway to confuse you so you run away from this tricky topic: Ciela uses dotNET coroutine so all the stuff that you use in NinjaThread behaves the same: yield return JumptToUnity() is a yield so it waits until the previous operation is done plus a frame then executes the rest.
Check out Ninja’s doc and if your’e confused about timing and game loop, build some tests with Debug.Log("doing dis " + Time.time); because it’s very hands-on stuff and all your questions can be answered by a few hours of you testing simple examples.
For example do some permutations of:
public UI.Text text;
void Start()
{
StartCoroutineAsync(ThreadedThing());
}
IEnumerator ThreadedThing(){
Debug.Log("starting "+Time.time);
text.text ="I start";
yield return JumpBack();
Debug.Log("in a separate thread "+Time.time);
text.text ="I crash!"; // API access, should be commented out
var thing = 0;
for(int i=0; i<100000000; i++){
thing += Mathf.sin(i);
}
yield return JumpToUnity();
Debug.Log("finished without freezing the game "+Time.time);
text.text = "finished without freezing the game "+Time.time.ToString();
}
Play around commenting and re-ording code inside ThreadedThing and see what breaks. text.text will, 99.99% of unity API calls will, Debug.Log or Mathf. won’t crap out - very hands on.
Stepping into async execution without solid foundation in c# is playing with fire, and at least familiarize yourself with the unity unique gameloop: Unity - Manual: Order of execution for event functions
Thanks, I’ll take both your tips. I’ll definitely check out the docs and try testing giving the code a spin. I’ll also try to limit it’s use to processes I think are quite heavy. Or as Hippocoder said, I’ll wait until I see what’s making my game slow and see if the technique is applicable to the issue. Anyways, one way or another I want to learn how to use it right, so thank you both.
What you said there is not really true.
MEC is an improved implementation of Unity’s coroutines. MEC has a range of extra features, runs faster, and uses less memory. In almost every case MEC coroutines will perform a lot better than the action arrays you are talking about here, laurentlavigne, since MEC is basically the same structure under the hood except it is also self-optimizing.
You would want something like MEC if you wanted to be able to run coroutines from non-Monobehavior classes, were using them heavily, needed more features and speed, or wanted to stop the garbage collector from causing frame rate jitters. You would use something like Thread Ninja if your app is running really heavy computations and you want to be able to do that without causing framerate jitters.
The two packages address different potential problems, so you have to ask yourself which of those problems you want to address, and keep in mind that if your answer is “none of those” then just use Unity’s coroutines.
Yeah, I was thinking of using both anyways 
(whenever they are necessary or applicable).
@Trinary the “self-optimizing” comment had me take a second look at MEC, is it RemoveUnused that you’re talking about?
@laurentlavigne A quick overview of the structure is that each coroutine is a process that gets put into a (coroutine) process list. The processes run one after another for as long as they are alive. Any process that finishes gets culled from the list automatically. MEC saves processing time by leaving holes in its process list and RemoveUnused comes by occasionally and removes those holes.
You were saying you could take all your possible actions and store them in a big array. An array like that would have to check for every possible action either every tick or every frame. You could upgrade such a structure with a system to register events if you liked, and then only process the events that were in use, but that would be basically reproducing a process pump. If you also took advantage of the yield return architecture then what you would have there would be a coroutine system. That’s what MEC is: A highly optimized coroutine system.
What I was saying is that a process pump is a self-optimizing structure when compared against an array of processes, and all coroutine systems are process pumps.
@Trinary I only use yield return in the context of unity coroutine, can you explain how those work?
(totally hijacking this thread in an awesome way)
I do get asked that a lot. I’m thinking of making a video going over that this weekend.
yield return was created by the .net foundation in order to make foreach statements work. It’s designed to return a list of elements one at a time. As soon as you use yield return in a function that returns an IEnumerator type then .net recognizes that and compiles the function differently. This different structure allows you to return a value to some code that will do something with that value and then pass control back to the IEnumerator function, which resumes executing where it left off.
Coroutines take advantage of this unique property of being able to return multiple values and resume where they left off each time. So yield return, which was originally designed to return a value in the list, is being used instead to pass control back to the process pump. When the process pump later calls the IEnumerator function that function will resume executing where it left off. This makes it really intuitive to structure a function that will execute over multiple frames. One of the only downsides is that we have to use commands (like yield return or yield break) that don’t seem very well named, since the whole structure was created for a completely different purpose.