Additional IL2CPP threads do not run smoothly.

I have a game where I am calculating the movement of thousands of particles on a separate thread made through System.Threading. The execution rate of this thread is controlled by stopwatch timing the thread and then doing Thread.Sleep for the appropriate amount to maintain a stable execution rate. On the original Mono AOT compile, this would result in smooth particle movement. However on an IL2CPP build the particles have a delay in their calculation every 30-40 cycles. So they don't go smooth, they kind of jitter.

I have tried timing this thread a few different ways now. I tried with a stopwatch, then I tried having it wait on a bool, that FixedUpdate set to true at set intervals to signify the thread should run. The stopwatch method minimized it the most, but still not as smooth as an original Mono AOT build.

For context, this is the game it is in:

All those particles moving are being moved by a different thread. See how smooth they move? Its like they are in the normal 30 fps game update loop.

That same thing built through IL2CPP and the particles movement will pause for a fraction of a millisecond every 30-40 seconds causing a jitter.

This makes me suspect a few things. The IL2CPP is spawning threads different than how Mono AOT was spawning threads resulting in different behavior. Or the IL2CPP threads are ignoring the 'priority' flag. I don't understand enough about the in-depth C++ implementation of these things. But I wanted to bring this to attention, the IL2CPP threads behave differently than Mono AOT threads, and Mono AOT threads behaved better, their execution rate was easier to maintain as smoother.

I'm hoping someone at Unity could look into this and compare Mono AOT thread creation to how IL2CPP threads are being made and hopefully identify a difference and correct. OR does anyone have any other ideas on how to time the execution rate of a thread made through System.Threading?

 

I have come to suspect that IL2CPP is not setting the thread priority on threads.

Can someone from Unity check whether or not this is true?

I wrote a C method using the low level pthread methods in mach to forcibly change the priority of a thread and that fixed it.

If anyone else needs it, this is the code for how you do it:

Code (CSharp):

1.  
2. #import <mach/mach.h>
3. #include <pthread.h>
4.  
5. void SetMoveThreadPriority()
6. {
7.     char name[256];
8.     mach_msg_type_number_t count;
9.     thread_act_array_t list;
10.     task_threads(mach_task_self(), &list, &count);
11.     for (int i = 0; i < count; ++i)
12.     {
13.         pthread_t pt = pthread_from_mach_thread_np(list[i]);
14.  
15.         if (pt)
16.         {
17.             name[0] = '\0';
18.             int rc = pthread_getname_np(pt, name, sizeof name);
19.             NSString *threadName = [[NSString alloc] initWithUTF8String:name];
20.             if ([threadName containsString:@"CellParticleMove"])
21.             {
22.                 int policy;
23.                 struct sched_param param;
24.                 memset(&param, 0, sizeof(struct sched_param));
25.                 pthread_getschedparam(pt, &policy, &param);
26.                 param.sched_priority = sched_get_priority_max(policy);
27.                 int error = pthread_setschedparam(pt, SCHED_RR, &param);
28.                 NSLog(@"CellParticleMove Set %d", error);
29.             }
30.         }
31.         else
32.         {
33.             NSLog(@"mach thread %u: no pthread found", list[i]);
34.         }
35.     }
36. }

That searches for a thread named CellParticleMove and changes it to be the highest priority possible.

 

I have put this into a open source library to deal with threading idiosyncrasies in Unity.
Available here:
https://github.com/rygo6/UniThread