Subject: Re: [boost] [Coroutine] What happened to WINFIBERS?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2016-04-11 06:36:27
On 11 Apr 2016 at 13:06, Mikhail Strelnikov wrote:
> 5) MS can add fibers support to VS debugger, or add performance counters
> related to fibers.
This will never happen as Fibers are deprecated and users are
strongly recommended to use User Mode Scheduling (Win7 or later only)
instead:
https://msdn.microsoft.com/en-us/library/windows/desktop/dd627187(v=vs
.85).aspx
I recently deployed a UMS based solution at work to implement an
ultra low worst case latency work scheduler which uses a "race to
work" algorithm to respond exceptionally quickly to an input change
on the first available CPU core. Worst case response times were under
10 microseconds no matter what foreground processes were doing, heavy
i/o, DMA etc. Not bad for Windows.
UMS threads, despite being scheduled by user mode code, are full fat
kernel threads as well. That means you can debug them as normal, call
any kernel API you like, no restrictions. Whenever your UMS thread
blocks on a syscall, your scheduler is told so you can schedule a
different thread. Whenever your UMS thread page faults, same thing
happens, and you are told the cause of the block. You are absolutely
permitted to move UMS threads between CPU cores any time you like,
you have complete carte blanche with regards to scheduling.
Suffice to say, I was impressed, and I'd highly recommend them as a
target for those needing coroutines/fibers. You'll never consider old
fashioned Windows Fibers ever again once you've used these.
The only downside is that writing the UMS scheduler is non-trivial,
and there is almost no documentation nor implementation code to study
so you are on your own. I eventually nailed a scheduler, but I worry
it is flawed in an unknown way. Also, I've discovered from experience
that COM does not like UMS threads, so don't call COM anything from
UMS threads which unfortunately rules out lots of stuff like anything
from WinRT, the cause is in the thread death callback COM installs to
deinit itself it causes the UMS thread to randomly hang during final
exit.
Finally, there are a ton of races between the UMS user space library
and the kernel implementation as soon as you schedule across more
than one CPU core, so you may spend a lot of time writing mitigation
code. None of the races are critical, they just present in the Ums*()
functions randomly failing sometimes and retrying them makes them
work.
I'm sure that Microsoft, if presented with repros for those bugs,
would fix them, it's just so few people have bothered with this very
useful API to date. I hope it doesn't go like Transacted NTFS due to
lack of public interest.
Niall
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/