Combining General Purpose C# Threads with Jobs

There are cases when large existing code-bases can be pushed onto a separate to keep the application running smoothly. Unfortunately, these systems can't just be rewritten to use jobs. For instance, I am currently running a heavy physics simulation on a separate thread using BulletSharp and then synchronizing the results.

My Question: If you need to keep a general purpose C# thread busy, how do you remove the logical core that is being used from the job system pool?

 

I don't think you would even want to do that. While it's possible that C# threads could interfere with optimal scheduling of job threads, I'm sure they have accounted for making the two play as nice together as possible. So unless your physics thread is doing something really bad,like always being in a busy wait loop, then you would basically be wasting part of a core. Which I'm thinking would almost always be worse then say a bit of extra context switching that might possibly happen as a result of C# and job thread scheduling have conflicting wants.

Managed threads don't map one to one to cores anyways, so what you want isn't really even possible.

 

I mean you can technically map a managed thread to one core can if you really really want to... (I haven't fully tested this).

It would be super-useful to reserve cores for unity job and managed threads, so you could avoid contention if it turns out to be a bottleneck.

 

Setting affinity to a core is not the same thing as locking a core to a specific thread or group of threads.

There are good reasons to pin threads to cores, mainly for cache coherency/context switching. But I doubt that's what the OP had in mind.

Reserving cpu time isn't really a thing like the OP is thinking. If the code is optimized well and not doing things like unnecessary locking and making good use of cache lines, then chances are the perceived issue just won't be one. And even if it is, you can't really know what the solution is until you get there. It's highly dependent on the actual work being done.

 

Great replies, very interesting, and it makes a lot of sense.

So I gather that when you yield a mono thread that was operating on a particular logical core, it might resume on a completely different one. I suppose this doesn't matter much from a cache perspective as new lines would have been brought in by whatever the next scheduled work was on that core anyway.