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

Subject: Re: [boost] [Coroutine] What happened to WINFIBERS?
From: Mikhail Strelnikov (mikhail.strelnikov_at_[hidden])
Date: 2016-04-12 13:31:28

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 <s_sourceforge_at_[hidden]>:

> 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
>