Update() method: No concurrent execution (?)

Dear all,

just a quick question: From reading the docs, it seems that if I have several MonoBehaviour-based classes on different (or the same) game objects, their Update() methods will be called in a random, but sequential order. Is this true? I.e. the Update() methods will NEVER be called concurrently (unless I play around with coroutines myself)?

The reason I am asking is that I'm considering integrating several Update() methods and I was wondering whether this might potentially slow things down.

It would be great if someone could confirm this.

Thanks!

plmx

 

Yes. And coroutines aren't concurrent either; they're simply a mechanism to spread execution out over multiple frames.

 

https://blogs.unity3d.com/2015/12/23/1k-update-calls/

You might find this article that unity put out of interest, especially the part about 10k updates vs using a manager to run updates.

 

I believe Unity API is not thread safe, and thus can only do one thing at a time on one thread.

You can use a Manager or Script Execution Order to determine the order of execution.

 

Thanks for all your replies, very helpful!! I can rely on non-concurrent execution in my Update() (and I guess also Start(), Awake(), etc.) methods then.

This of course begs the question how to run things in a truly concurrent way (if coroutines aren't doing this, as was mentioned). I suspect I have to start threads the "old" (C#) way - right? And find a way to sync back to Unity's main thread afterwards, if the API isn't thread safe.

By the way, I guess Unity is doing internal stuff in other threads to take advantage of multicore processors? E.g. physics or talking to the GPU or other stuff? Does anyone have info (link?) on the concurrency-related internal workings of the engine?

Thanks!

plmx

 

I believe that the only thing that Unity is not putting into the main process thread is graphical (obviously, because it's put onto the GPU)
From what I've read, that's all the multi-threading that Unity does out-of-the-box

 

Unity does a fair amount of multithreading where feasible such as skinning/Mecanim/cloth/particles/etc. A far as user code goes, you can use threads with thread-safe Mono/.NET code only and sync with the main thread.

--Eric

 

Hi,

thanks a lot! I'll take away the message that all relevant scripting methods for me are non-concurrent unless I resort to c# threads, in which case I should sync back to Unity's thread once I'm done. Unity does use multithreading but outside of the developer's influence.

I can work with that. ;-)

Thanks again!

-plmx

 

The graph on this page is helpful. https://docs.unity3d.com/Manual/ExecutionOrder.html

 

We use multithreading in Unity. Once you build a thread-safe method to communicate with the main thread it works rather well. Significant effort is required though, and I don't think Unity's profiler is as effective when you have other threads running.

 

For the sequential execution order, yes; however, it doesn't address concurrency.

Thanks for the experience report!

-plmx

 

A very light-weight way to do move stuff to other threads is through Thread Ninja. It's free too!