runtime: use user-mode scheduling on Windows

[dvyukov]

Runtime could benefit from OS support for user-mode scheduling.
Namely, UMS on windows:
http://msdn.microsoft.com/en-us/library/windows/desktop/dd627187(v=vs.85).aspx
and switchto domains on linux:
http://www.youtube.com/watch?v=KXuZi9aeGTw

This would allow to determine when a thread in syscall/cgocall actually block. Which
would allow to reduce non-blocking syscall/cgocall overhead by delaying most of the work
till the actual blocking; and to prevent CPU oversubscription by maintaing total of
GOMAXPROCS threads running both Go and C/syscall code.

The obvious downside is increased complexity and lots of OS-specific code.

[minux]

Comment 1:

maintaining total GOMAXPROCS threading running both go and cgo code
will break at least one misc/cgo/test case though.
However, if we count goroutines running cgo code towards to GOMAXPROCS,
then I think we can dramatically reduce cgocall overhead (no scheduler coordination
except mark that it enters cgocall). Am I correct?

[dvyukov]

Comment 2:

You are correct.
To prevent deadlocks scheduler can still create new threads to run Go, but much more
lazily (so that it mostly does not happen for normal programs).

[gopherbot]

CL https://golang.org/cl/20834 mentions this issue.

[zx2c4]

I'm wondering if there's still interest in doing this, given the evolution of the runtime in the last 6 years. At cursory glance, it looks appealing.

[networkimprov]

cc @aclements @prattmic @alexbrainman @mattn

[ianlancetaylor]

According to #8687 (comment) User Mode Scheduling is considered to be deprecated, and will not be supported on ARM platforms.

So I suspect we should just close this issue.

[qiulaidongfeng]

cc @golang/runtime
windows 11 not support UMS , this issue should be close.

[prattmic]

Thanks. This is clearly documented are unsupported on https://learn.microsoft.com/en-us/windows/win32/procthread/user-mode-scheduling?redirectedfrom=MSDN.