Thanks, Niall, this is all very helpful (expecially about COM issue).
But since when Fibers are deprecated? I can't find anything about it.
2016-04-11 13:36 GMT+03:00 Niall Douglas
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/
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost