[Coroutine] What happened to WINFIBERS?
When testing 1.61 beta I couldn't find any reference to BOOST_USE_WINFIBERS in the sources and also the WinFibers implementation-file "execution_context_winfib.ipp" was missing. Has support for windos-fibers been removed? Tobias -- View this message in context: http://boost.2283326.n4.nabble.com/Coroutine-What-happened-to-WINFIBERS-tp46... Sent from the Boost - Dev mailing list archive at Nabble.com.
2016-04-11 8:00 GMT+02:00 Tobias Loew <Tobias.Loew@steag.com>:
When testing 1.61 beta I couldn't find any reference to BOOST_USE_WINFIBERS in the sources and also the WinFibers implementation-file "execution_context_winfib.ipp" was missing. Has support for windos-fibers been removed?
yes
1) Calling functions like GetModuleFileName, GetTimeZoneInformation without BOOST_USE_WINFIBERS was leading to crash in the past (see https://svn.boost.org/trac/boost/ticket/10657 ). Looks like it is fixed now, but will this fix work in future Windows versions? Can they change something in Windows 11 so that old application using Boost.Context will crash? 2) I have an application that (knowing BOOST_USE_WINFIBERS is on) uses ::GetCurrentFiber(). Could you please recommend on how to migrate it to upcoming Boost? execution_context::current looks promising, but it is only available in v1, not in v2 (which is default). Should I compile with BOOST_EXECUTION_CONTEXT=1? What is disadvantage of this? 3) There is CreateFiberEx that allows to reserve for example 1GB (x64) of memory for fiber stack, but commit only small portion of it. Isn't this good alternative for segmented stacks on Windows? 4) Could Boost.Context be made header-only using Windows fibers? 5) MS can add fibers support to VS debugger, or add performance counters related to fibers. 2016-04-11 10:16 GMT+03:00 Oliver Kowalke <oliver.kowalke@gmail.com>:
2016-04-11 8:00 GMT+02:00 Tobias Loew <Tobias.Loew@steag.com>:
When testing 1.61 beta I couldn't find any reference to BOOST_USE_WINFIBERS in the sources and also the WinFibers implementation-file "execution_context_winfib.ipp" was missing. Has support for windos-fibers been removed?
yes
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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/
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@nedprod.com>:
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
2016-04-11 12:06 GMT+02:00 Mikhail Strelnikov <mikhail.strelnikov@gmail.com> :
1) Calling functions like GetModuleFileName, GetTimeZoneInformation without BOOST_USE_WINFIBERS was leading to crash in the past (see https://svn.boost.org/trac/boost/ticket/10657 ). Looks like it is fixed now, but will this fix work in future Windows versions? Can they change something in Windows 11 so that old application using Boost.Context will crash?
Maybe - Windows is closed source and MS did not document all parts of the TEB. It is likely that some TEB-parts, that needs to be swapped during context switch, aren't touched in boost.context.
2) I have an application that (knowing BOOST_USE_WINFIBERS is on) uses ::GetCurrentFiber(). Could you please recommend on how to migrate it to upcoming Boost? execution_context::current looks promising, but it is only available in v1, not in v2 (which is default). Should I compile with BOOST_EXECUTION_CONTEXT=1? What is disadvantage of this?
v1 is slower (access to TLS) - v1 uses the same assembler code as v2 v1 is required to support segmented stacks
Are there technical reasons for removing Fiber-support? I had similar problems as Mikhail and using Fibers was the only way to get rid of a dubious crash when terminating the coroutine (http://boost.2283326.n4.nabble.com/coroutine-x86-msvc11-stack-corruption-td4...). -- View this message in context: http://boost.2283326.n4.nabble.com/Coroutine-What-happened-to-WINFIBERS-tp46... Sent from the Boost - Dev mailing list archive at Nabble.com.
participants (4)
-
Mikhail Strelnikov -
Niall Douglas -
Oliver Kowalke -
Tobias Loew