Is it safe to run managed code on Windows UMS threads?

[john-h-k]

Pretty self explanatory - I know fibres are not, but I wonder if windows UMS threads can be safely run with managed code.

https://docs.microsoft.com/en-us/windows/win32/procthread/user-mode-scheduling

[danmoseley]

@kouvel

[davidfowl]

I think the problem isn't so much managed code (though maybe there are other complications like how thread suspension works for things like GC), but code that is generally unware of the UMS context. What happens when you call blocking APIs? It won't yield to the scheduler because the code in .NET isn't aware (unless UMS interoperates with the system APIs that the CLR uses).

https://docs.microsoft.com/en-us/windows/win32/procthread/user-mode-scheduling#ums-best-practices

UMS worker threads should not assume the system scheduler is being used. This assumption can have subtle effects; for example, if a thread in the unknown code sets a thread priority or affinity, the UMS scheduler might still override it. Code that assumes the system scheduler is being used may not behave as expected and may break when called by a UMS thread.

I don't know if any code assumes this but it's something to look out for if you do this.

I'm interested to know what you find and maybe you'll need to make some changes to the CLR to make it work smoothly.

cc @jkotas

[reflectronic]

unless UMS interoperates with the system APIs that the CLR uses

When a UMS thread blocks in a system call (e.g. by calling WaitForSingleObject), the scheduler is given back control of the processor. I think most blocking APIs in .NET end up waiting in the kernel, either through WaitHandle or Monitor etc.

[jkotas]

I do not see anything that would prevent it from running safely (ie not crash or deadlock randomly), assuming that the UMS scheduler itself is not implemented in managed code.

I think more of the challenge is in making it work well (ie faster than what you get from regular scheduler).

I'm interested to know what you find

+1