.Net 4.6 - Playing with async Tasks. Some thoughts.

Unity Engine
1

So I have been playing with Tasks inside of Unity since the beta versions of 2017 which had a somewhat stable 4.6 backend/Api level, and have found that they might be fairly useful in the future. I had a pretty easy time implementing some basic stuff with them, such as netcode, web requests, and text file hotloading. However, there are some issues with doing certain things with Tasks.

One unfortunate thing, is that Unity was clearly not made with multi threading or tasks in mind, and many features in Unity simply won’t work off of the main thread, throwing an exception if they are. Some things can easily be cached by some behaviour which regularly updates some of its member fields to the values (such as the running/paused state of the editor/player), but for other things, they are basically completely locked from being accessed, such as most members of most asset types (Texture2D and AudioClip for example), and their constructors. Same with creating/manipulating features of GameObjects, such as adding components or changing the Transform of a GameObject.

It was especially painful when I was writing a custom async resource loader. I still need to construct the Texture2D/AudioClip instances and feed them data on the main thread. I had a little queue that I could pass the code into as a delegate to run it on the main thread, and then stall the tasks by repeatedly delaying until some condition was met. This worked, and I was able to load textures/sounds, however, I know that this pattern is not robust, especially for tasks, and it still causes minor hitches when the textures/sounds are constructed/passed data.

I am wondering if, now that since Unity is upgrading the .Net backend, there are any plans to make it easier to create Thread-ed/Task-ed code run on top of Unity? I can see a fair bit of potential in using Tasks to handle things that don’t need to happen right away, but might stall the main thread if they were done on it. It could also be as easy as allowing tasks a synchronization context that allows them to access such things if they need to (like the provided UI context inside of Windows Forms)

2

You can see the recent Unite talk about the upcoming c# job system:

That being said I don’t think they will open up the standard API to be accessed from multiple threads anytime soon.

3

Well it’s more important to open up the engine to “what do we want to do a lot with?” and this is usually going to be particle systems and transforms. So I guess opening those parts up will have the biggest impact.

4

That’s pretty impressive. I’ve been seeing more stuff on data-driven/data-oriented code, which seems like exactly what they are going for here (I think he even mentions data-oriented design a few times). The temp/frame/persistent allocators would be nice to have just for optimizing the data layouts, and the Component System seems like a very nice way to do things in mass.

I like the job system at a high level, and based on how he’s saying it compiles the code with a narrow domain so they can make more specific optimizations. I don’t know how flexible it might be, but it would be fun to see what can be done with it. Their system seems most useful for scheduling things that need to happen on a per-frame basis.

Tasks still seem useful for things when you don’t need them to sync up to the main thread regularly, and still want to maintain frame rate (ex, file or network IO)

I bet it would be easy to write projectile/enemy systems for curtain-fire shmups with this Job Scheduler.