Background to Main and back threading

[steady ether]

Maybe we gotta keep this in a thread 😄 Ill check later on my scripts, but that seems to be a bigger thing that might or might not work at some point

[vivid oasis]

I really doubt there's such a thing as invoking something on a different thread. That's basically the same as if you take an actual real life thread, cut it in half and stuff in a different thread in the middle. And it's not gonna work if you do that.

[final bobcat]

Here is something I made 3 years ago that acts like that dispatcher: https://hatebin.com/tlkbntuldf

The idea is that update in a monobehaviour calls ActionExecutionService.Execute. This is thread safe so you can call ActionExecutionService.Add from another thread.

For Unity 2023, use these:
https://docs.unity3d.com/2023.1/Documentation/ScriptReference/Awaitable.html
https://docs.unity3d.com/2023.1/Documentation/ScriptReference/Awaitable.BackgroundThreadAsync.html
https://docs.unity3d.com/2023.1/Documentation/ScriptReference/Awaitable.MainThreadAsync.html

[vivid oasis]

You synchronize between threads by setting changing some state from one thread, that can be picked on the other thread to alter it's execution.

Yeah, a queue of delegates is a common way to do something like that.

[final bobcat]

The problem he has is that he wants to return to the background thread that originally called the method that had to happen on the main thread.

I know you can have access to a certain thread context, but idk if you can make this work at all

[vivid oasis]

you can't "call a method on the other thread" though.

[steady ether]

You would do the same vice versa as with main

[final bobcat]

No, what he wants is this:

await goToMainThread();
var valueForBackgroundThread = mainThreadMethod();
await goToBackgroundThread(valueForBackgroundThread);
backgroundThread();

Otherwise yes - you can just create a new thread.

So unless I am completely mistaken on what he wants now, I think it's very unlikely you can do this.

I'm referring to this by the way https://discordapp.com/channels/489222168727519232/763495187787677697/1069940613455282197

Since he talks about getting a response

[vivid oasis]

I suppose this is not impossible, but it would require tinkering with the synchronization context. Still, it doesn't mean that you "jump" between threads. The right thread simply picks the execution where the other thread left it.

[final bobcat]

Yeah that's what I thought.

[vivid oasis]

That being said, I think Thread Ninja asset implement something like that with coroutines.
https://assetstore.unity.com/packages/tools/thread-ninja-multithread-coroutine-15717

[final bobcat]

Interesting

Let me check what happends there. Maybe it can also be done using an async-await pattern.

[vivid oasis]

Most likely

[final bobcat]

A lot of lock statements

I'm not too familiar with lock since I always use SemaphoreSlim

[wraith forge]

This is essentially what I want to do yes.

await goToMainThread();
var result = HandleCommand(command);
await goToBackgroundThread();
return result;

[final bobcat]

See this message about Unity 2023

@wraith forge

[wraith forge]

I'm not sure I'm comfortable about using a beta release at this time. I'll have a look around to see if I can find anything. Thanks

If I don't use Task.Run the context should remain the same yes? Then I won't any issues accessing components

Well it works. I'll have to assess the performance impact but it should be better than context switching

[final bobcat]

Tasks in Unity all run on the main thread, just like how a Coroutine works

This is because the state machine that a Task compiles into is different in Unity compared to regular c#, specifically to support Unity methods

[wraith forge]

Ah, I was using a .Net standard library for Tasks

[final bobcat]

If you do this, your main thread will be blocked though, so it depends on your needs

[final bobcat]

Idk if external libraries also work like this

Either way, Unity is working on supporting it better