Thread priorities on Unix

[RalfKornmannEnvision]

As a game developer I like to have some control over the thread priorities. 

I checked the code and it's not implemented, yet. Is there a reason beside nobody had the time yet?
Based on the code there are  two missing parts

• Getting a handle back to the managed part during thread creation.
• Add native functions to get and set the priority

Beside of converting the priorities the actual set and get functions should be pretty easy. The question here is only if the conversion should be done on the C# or C side?

The handle might be more tricky as pthread_t doesn't need to be a numeric type. 

Therefore my idea is to store the handle in the managed part a a intptr. For systems that uses a numeric type for pthread_t that is smaller than a pointer we can just use it direct. On other systems we need to allocate some memory to store a copy of pthread_t and the managed part will store a pointer to this memory. But we need to make sure the memory is freed when the managed thread object is collected. 

The other option would be doing it in the same way as socket addresses are store. The managed part asks the native how much space is needed. It creates a byte array and every time a native call is made the array is pinned. While this is very straight forward it might be less efficent. But I don't expect that many calls there.

[Suchiman]

I remember stumbling upon this while hacking on the GC, specifically

corert/src/Native/gc/unix/gcenv.unix.cpp

Lines 1028 to 1038 in a7ff563

	// Boosts the calling thread's thread priority to a level higher than the default
	// for new threads.
	// Parameters:
	// None.
	// Return:
	// true if the priority boost was successful, false otherwise.
	bool GCToOSInterface::BoostThreadPriority()
	{
	// [LOCALGC TODO] Thread priority for unix
	return false;
	}

(which should be fixed as well) but i don't remember the exact reason. I thought i've read the priority cannot be changed after thread creation but that appears to be false.

[RalfKornmannEnvision]

I remember seeing this when porting to the Switch/PlayStation

The place I was refering to is here:

corert/src/System.Private.CoreLib/src/System/Threading/Thread.CoreRT.Unix.cs

Lines 32 to 40 in a7ff563

	private ThreadPriority GetPriorityLive()
	{
	return ThreadPriority.Normal;
	}
	private bool SetPriorityLive(ThreadPriority priority)
	{
	return true;
	}

Edit: Did a quick check. BoostThreadPriority is currently only used by the server GC for the GC threads. But it should be possible to implment it for Unix. But as I currently don't run a server GC I cannot test it

Edit2: Did some more digging. It seems that in many cases the OS is configured in a way that a regular process cannot change the thread priority. Therefore properly nobody cared that much. A quick check in the mono and runtime source showed that both have the code to support it when the OS allows it. Therefore I think we should have it in the same way in CoreRT.

PS: while trying around a little bit i fixed this TODO
// TODO: Figure out which scheduler to use, the default one doesn't seem to
// support per thread priorities.

It still has the limitation that it will only work when the OS allows it but if not it will just do nothing which is the same as now. I can make a PR for it 

[jkotas]

. It seems that in many cases the OS is configured in a way that a regular process cannot change the thread priority. Therefore properly nobody cared that much

Yes, that's correct.

It still has the limitation that it will only work when the OS allows it but if not it will just do nothing which is the same as now. I can make a PR for it

💯