Can I open new threads to run on different processors in unity3d? and can I put selected gameObjects into different threads?
Yes, you can create threads to take advantage of multiple cores but the Unity APIs are not thread safe. They’ll only work properly on the main thread.
2 Likes
How about the new job system? I am not fully clear of its potential. 
If only unity3d would allow a way to make it thread safe. It can remain the same as it is now, just giving a way to call some function to make certain parts of it thread safe. Well I figured out a work around for this problem. It will fit into my design really well, because it breaks the project into different parts, making each part simple.
Unity supports up to 100% core utilisation with threading. Try reading beta forum. Stop dictating the shape of tech, it doesn’t and can’t work like you think it can.
3 Likes
Sure, some things can’t be made thread-safe. But some things could. For example, it seems reasonable that accessing the application version (Application.version) should be possible from a background thread. And yet, Unity won’t allow it.
Why would Unity task incredibly expensive developers (most top in their fields) on adding cruft to the engine to support things like Application.version ? I mean that’s a huge WTF for me.
When thinking about what engine features to thread (and have access to - which is the only relevant thing), we first think about what we need access to. Transforms are the first big one, and that’s covered. Next up is general data, and that’s also covered (both in 2018) - what is missing?
The rest can be done fine in C# land.
The fact that that’s a huge WTF for you is a huge WTF for me 
The complaint of the API not being callable from a background thread comes up again and again and again. There’s this general feedback item but also plenty of specific “this should be accessible from background thread” items as well. Forum threads like this one always pop up as well.
Perhaps they could keep their incredibly expensive developers on the harder tasks and hire entry level devs to do the simple jobs.
1 Like
Cache it when you run the program… ? … I mean, if you’re writing multi threaded systems I think you can figure out how to keep a string reference around.
3 Likes
Of course. But of course, it would be better if that were done behind the API rather than having duplicate cached versions of all these variables in all these projects, and maintaining it for Unity’s API changes.
You would be adding needless overhead, not just for the applications that don’t need threading but for the applications that need it too, because any solution by the game engine developers would need to be able to handle everyone and not for just one scenario.
No. There doesn’t need to be additional overhead. And yes it’s needed by some developers.
Only way to avoid the overhead would be to maintain two sets of APIs. One of them thread-safe and one not. Unity already has enough on their plate to implement. We don’t need to complicate it because some people can’t figure out how to thread their apps.
Not when you take into account the big picture. If you have a system that is mostly not thread safe, you want very clear logical boundaries there that are consistent. You don’t just remove guards on stuff that happens to be thread safe now, that’s just begging for disaster.
It’s also considered bad practice pretty much everywhere to have just part of an api thread safe. At the very least there should be a logical pattern to it. Not just randomly this is and that isn’t.
AFAIK (from what I recall seeing at the conference) the new job system takes advantage of CPU access prediction. Nothing to do with threading.
I’m sure someone will correct me on this if I’m mistaken.
You can make your engine multi threaded without huge safety overheads?
Bulls***.
If you write your code using the new C# job system in 2018.1, then:
- the engine can run your code across all CPU cores
- we can verify that your code is thread safe in the Editor, and then turn off all those checks in the Player
- following the constraints on jobified code (e.g. no reference types) will push you towards more cache-efficient memory usage patterns and prepare you for the ECS
1 Like
Actually, it’s considered bad practice pretty much everywhere for static data not to be thread safe. See here: https://docs.microsoft.com/en-us/dotnet/standard/threading/managed-threading-best-practices#recommendations-for-class-libraries which says “Make static data (Shared in Visual Basic) thread safe by default”.
Don’t conflate state-altering methods and static pieces of information. They’re different.
I didn’t say anything close to that 
You should probably re-read what I wrote above. Make everything thread-safe? Yeah that’s a lot of overhead and agree it shouldn’t be made that way. I didn’t say make everything thread-safe. Static data doesn’t need to be made thread-safe. It’s unchanging and has no side-effects so it’s thread-safe by nature. It’s likely more overhead for Unity to check the thread before accessing the data so it can display the error.
I don’t think you grasp at all what true multithreading and the job system is. I think you are highly confusing it with coroutines and green threads.
True multithreads can’t be thread safe, you just take extra care of when, and how you bounce information between the threads. I mean extra care, one collision, one double access to the same resource at the same time and you are gonna have some fun experiences watching your entire computer lock up.
Top devs in their field yes, they are doing the right thing. They are making this job system, doing all of the complicated start threads, merge threads, pass information etc in the background we are not even going to have to worry about it. Let me tell ya I have been testing it hard and they are doing a great job. It IS NOT EASY, takes careful decisions planning and absultely has to be bug free. Sure many times the program will just crash on mistake, or youll get a long hiccup BUT if core 0 gets thread dead from a multithreading mistake, thats where your kernal is, your computer going to give you a lovely blue screen.
The reason static data is considered, and well making myself a liar it really is thread safe. Is because it is static. Since it doesn’t change and nothing is changing it, only being read, you cant have 2 things trying to change its value at the same time. So it just kinda works, not really truely safe but you wont break it either.
In Java we pretty much never consider anything thread safe unless it is private static final lol. Nothings gonna break that.
You quoted that out of context.