Re: [boost] [Coroutine] What happened to WINFIBERS?

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/