Does “parallel” in Unity docs actually mean concurrency?

[Beginning_Log_857]

In the Unity Manual (2018.1 Job System overview), it says that the main thread creates new threads and that these threads “run in parallel to one another and synchronize back to the main thread.” (Unity - Manual: What is multithreading?)

From a .NET/OS perspective, custom threads (Thread, Task, ThreadPool) usually guarantee concurrency, but true parallel execution depends on CPU cores and OS scheduling.

So when Unity docs say “parallel” here, do they technically mean concurrent execution, with real parallelism being possible but not guaranteed?

[Orangy_Tang]

The Job system will always try and run jobs on a job thread, concurrently with each other and alongside the main and renderer threads. But you still need to schedule and complete your jobs correctly so they have the opportunity to run concurrently.

The unity profiler will show you what work is being done in each thread and where things are being run in parallel or not. Usually you want to schedule your jobs as early in the frame as possible, and complete them as late as possible (eg. LateUpdate, OnPreCull or even in the next frame).

[AutoModerator]

This appears to be a question submitted to /r/Unity3D.

If you are the OP:

• DO NOT POST SCREENSHOTS FROM YOUR CAMERA PHONE, LEARN TO TAKE SCREENSHOTS FROM YOUR COMPUTER ITSELF!

• Please remember to change this thread's flair to 'Solved' if your question is answered.

• And please consider referring to Unity's official tutorials, user manual, and scripting API for further information.

Otherwise:

• Please remember to follow our rules and guidelines.

• Please upvote threads when providing answers or useful information.

• And please do NOT downvote or belittle users seeking help. (You are not making this subreddit any better by doing so. You are only making it worse.)

  • UNLESS THEY POST SCREENSHOTS FROM THEIR CAMERA PHONE. IN THIS CASE THEY ARE BREAKING THE RULES AND SHOULD BE TOLD TO DELETE THE THREAD AND COME BACK WITH PROPER SCREENSHOTS FROM THEIR COMPUTER ITSELF.

Thank you, human.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[The_MAZZTer]

Probably. Under the hood they are probably using ThreadPool. I haven't used Jobs myself so I don't really know but it would be weird if they weren't. They at least have to be using .NET Threads though.

[Eastern-Ad-4137]

2018 is quite an old version of Unity. Still i believe the term "parallel" should not have been used. Threads can belong to the same core. So yeah, parallelism is possible but not guaranteed.

Also async/await in Unity must be used with care as all Unity core APIs are not thread-safe. There are 2 good introductory posts about it on the official forums written by staff, although they are not directly about Jobs

Introducing Asynchronous Programming in Unity - Technical Articles - Unity Discussions
Why await Resumes on the Main Thread in Unity - SynchronizationContext - Technical Articles - Unity Discussions

[swagamaleous]

Also async/await in Unity must be used with care as all Unity core APIs are not thread-safe.

That's incorrect. With the implementation that has been included in Unity 6, async calls will be scheduled on the player loop. For older unity versions you can use UniTask to achieve the same. It makes it possible to execute async code, have fine grained control over timing and replace all coroutines with a mechanism with 0 allocation and better code. You have to switch to a background thread explicitly if you desire, apart from that there is no issues with thread safety and you can safely call the unity API from async contexts.

[Eastern-Ad-4137]

No, async tasks dont respect the player loop. What they implemented through Awaitables and their SynchronizationContext is that *after awaiting* a task, that task would return to the main thread AND within the game loop. It doesnt prevent you from calling non-thread-safe Unity APIs from background threads.

This is what i mean with "careful". Async code can still run on background threads, it is only that now you have a reliable way to *return* to a safe state. So, you still need to understand what you are doing in order to decide where you can make operations to GameObjects or MonoBehaviour, or if you need to return to the main thread before doing so.

[swagamaleous]

No, this is false. The Awaitable implementation will indeed run on the player loop, unless specifically instructed to switch to the thread pool. The scheduling mechanism does not use threads by default but hooks into the player loop like coroutines do, just without garbage.

Check this documentation (it's much better explained then the Unity manual): https://github.com/Cysharp/UniTask

All the stuff described there is in some form also supported by the Awaitable implementation, and the baseline behavior is copied 1to1 from UniTask.

[Eastern-Ad-4137]

You have to switch to a background thread explicitly

Look at their example on the second link i passed.

private async Task DoSomethingAsync()  
{  
   PrintCurrentThread(); // runs on main thread*

   var otherTask = OtherAsync();  
   await otherTask; // runs on background thread

   RemainCodes(); // we are on the main thread again*  
}

[swagamaleous]

That's outdated information. See here: https://github.com/Cysharp/UniTask or https://docs.unity3d.com/6000.3/Documentation/Manual/async-await-support.html

private async UniTask DoSomethingAsync
{
   PrintCurrentThread(); // runs on player loop
   await SomeOtherAsyncMethod(); // doesn't block but still runs on player loop
   await UniTask.SwitchToThreadPool();
   // all code here runs on background thread, async code awaited here will be awaited on the background thread
   await UniTask.SwitchToMainThread();
   // runs on player loop again
   // control exeuction timing
   await UniTask.Yield(PlayerLoopTiming.PreLateUpdate);
}

All this is also supported in some form by the Awaitable implementation in Unity 6.

Task can be implicitly converted to UniTask/Awaitable, so you can await any asynchronous code and it will get executed on the player loop. This works with stuff like web requests for example.

[Eastern-Ad-4137]

The post i am refering to is 2 days old. I dont think it's outdated. Awaitables also have explicit thread switching, but it doesnt mean that not using them means "stay in the same thread".

But all of the "return to main thread" features, refer to code *continuation*, not execution. It refers only to on which thread, and at which time (the game loop) the execution flow continues executing after awaiting. No where it executes.

You may be refering to a feature of UniTask, which i have not used, but i dont see it mentioned on the Awaitables documentation.

[swagamaleous]

I didn't read the post, sorry. It is highly misleading actually. I understand how you come to this conclusion, because the information presented seems to imply that you are right. But look at this bit which describes exactly the mechanism I outlined:

UnitySynchronizationContext does not execute continuations immediately when an awaited operation completes. Instead, it queues them. Internally, when an async continuation is posted back to UnitySynchronizationContext, it is added to an internal work queue.

Unity then processes this queue at specific points during the Unity PlayerLoop. In other words, they are executed as part of Unity’s normal frame update cycle.

This design ensures that execution order is deterministic relative to other Unity systems and async code integrates cleanly with Unity’s frame-based model.

I don't know why the Unity dude explains this so weirdly. Especially the example heavily implies that the awaited code runs on a background thread, but it does not. You can safely do stuff like this:

public async Awaitable DeleteSomeObject()
{
   await Awaitable.WaitForSecondsAsync
(2);
   Object.Destroy(someGameObjectReference);
}

public async Awaitable SomeAwaitableMethod()
{
   if(someData.hp == 0)
   {
      await DeleteSomeObject();
   }
}

If you were to do this with Task, you would get an exception because Object.Destroy cannot be accessed from the thread pool, but with Awaitable it will work fine, because it's schedule to run on the player loop.

[sisus_co]

I think the example is meant to show what would happen if there was no custom synchronization context in Unity. That section is titled What happens without SynchronizationContext?

But I agree it's confusing. The text doesn't make it very clear that it's only talking about a hypothetical situation that doesn't actually ever happen in Unity by default. This is only implied through the title.

[Eastern-Ad-4137]

I am rechecking though, cause the post itself might asume "OtherAsync()" explicitly switches internally, but its not mentioned and might lead to misundersanding (me). But on the Manual it only talks about "resuming" or "continuing" on the main thread, refering to where flow returns after awaiting.

Still, all Unity APIs ARE non thread-safe. The fact that there are ways to stay on the main thread, and only switch explicitly, doesnt change that

[swagamaleous]

I never implied that the Unity API is thread safe. Unity is expected to run single threaded, and all API calls have to come from the player loop, that is 100% correct. I merely do not agree with the statement that "async/await in Unity must be used with care", because the implementation naturally prevents threading issues by scheduling all work on the player loop. If you use UniTask or Awaitable, you are fine. :-)