Freigeben über

Fibers, and other mad stuff that you shouldn’t use

  • Artikel

In Cyrus’s last post (https://blogs.msdn.com/cyrusn/archive/2004/06/07/149893.aspx) he wrote:

“...i got a great email from Neil pointing me to this article on fibers and coroutines in .Net“

I am not sure I can say this strongly enough. DON’T USE FIBERS IN A MANAGED APPLICATION. The 1.1/1.0 runtime will deadlock if you try to managed debug a managed application that used fibers. The CLR team did a lot of work for fiber support in the 2.0 runtime, but it still won't support debugging.  You should only use fibers if:

  • You are porting code that already uses a threading library (never true for managed code)
    -or-
  • You are writing a database, and are willing to devote years of dev time to trying to get the best performance possible.

Fibers are inherently painful to debug. Most code is not fiber safe because fibers don’t work with all of the normal thread synchronization code, or any code that uses thread local storage.

Too often, programs like to use some new fancy feature. When writing code, it is important to ask:

  1. Will the next owner of this code be able to understand this?
  2. How difficult will this code be to debug?
  3. How difficult would it be to support this code after the product ships?

Fibers fail all of these tests.

Comments

  • Anonymous
    June 07, 2004
    I remember reading/hearing somewhere that SQL Server uses fibers a great deal. Is this the case? Is that why CLR 2.0 has improved fiber support?
  • Anonymous
    June 07, 2004
    SQL Server is one of the only applications that should use fibers. It can either be run in thread mode (default) or fiber mode. Chris Brumme had an interesting blog about the support that the CLR did for hosting (http://blogs.msdn.com/cbrumme/archive/2004/02/21/77595.aspx).
  • Anonymous
    June 07, 2004
    I'll point out that we're planning (as always everything can change) on shipping an SDK sample in Whidbey that allows you to do managed co-routines using the Whidbey hosting APIs. I would also strongly recommend that you only pursue fibers on Whidbey (if anywhere).

    Gregg's comments are spot on. Fiber mode is only for applications that really need to tune every bit of performance out of the machine. And even then its best gains are seen on multi processor machines. And it really is a pain to debug when something goes wrong in fiber mode (~*kb ? ha-ha!). Let alone just implementing it, and then making it perform well!

    But if you do choose to use them I hope you'll find the CLR half of the implementation to be good :). I think you'll also find that the hosting APIs may offer you other opportunities to control performance (eg, via hosting the thread pool). Finally there are probably other features on the Whidbey hosting APIs that your program would benefit from more than fiber mode. There's a lot of cool stuff there!