18

I'm joining a C# project in which the developers are heavily using Fibers. Before this project I haven't even heard of them and previously used async await and Threads and BackgroundWorkers to my multitasking operations. Today I was asking them why they used Fibers and the main developer said that it's easier for him to debug. Meaning he knows which thread a particular function has come from and even could access the variables higher in the stack.

I was wondering what are the advantages and disadvantages of using Fibers vs using the new async await and using Threads.

PS: We're using .Net 4.5

Yuval Itzchakov
  • 146,575
  • 32
  • 257
  • 321
Alireza Noori
  • 14,961
  • 30
  • 95
  • 179
  • 3
    What Fiber implementation are you referring to the use of? The [Windows Fiber API](https://msdn.microsoft.com/en-us/library/windows/desktop/ms682661(v=vs.85).aspx)? – timmyl Jul 04 '15 at 13:42
  • 1
    It is true that when you pause the debugger you can't see what the app does because all threads are doing nothing most of the time. That is a big drawback of async IO. I would never recommend fibers, though. – usr Jul 04 '15 at 14:09
  • 1
    Fibers are more expensive than tasks. Fibers require 1MB of memory for the stack. Tasks require memory for local variables, but they use the scheduler's stack. – Raymond Chen Jul 04 '15 at 16:39
  • @timmyl sorry for answering late. It is implemented manually using Enumarables – Alireza Noori Jul 06 '15 at 18:52
  • In that case, since its not OS level Fibers, the one case I can think of is a strict memory footprint constraint, so you want your application running on one thread + the normal CLR infrastructure threads. Cooperative multitasking with enumerators is one way to accomplish that. That said its a lot of work. I think you'd need a strong reason to go that route as the CLR thread pool and asynchronous I/O are pretty robust. It might help to give some more context about the type of system you're working on and any special constraints it has. – timmyl Jul 07 '15 at 19:44

1 Answers1

18

I was asking them why they used Fibers and the main developer said that it's easier for him to debug. Meaning he knows which thread a particular function has come from and even could access the variables higher in the stack.

That sounds outright peculiar. When using the Task Parallel Library with custom schedulers other than the default ThreadPoolTaskScheduler, you can, yourself, decide how your tasks get scheduled (and it isn't necessarily on new threads). async-await on the other hand provides you a convenient way of doing asynchronous IO. VS gives you the ability to debug asynchronous code using as if it were executing synchronously.

In order to use fibers, one would have to invoke unmanaged API's, as .NET doesn't offer any managed wrappers in the BCL. Even the docs of fibers clearly say there isn't a clear advantage to using them:

In general, fibers do not provide advantages over a well-designed multithreaded application. However, using fibers can make it easier to port applications that were designed to schedule their own threads.

I was wondering what are the advantages and disadvantages of using Fibers vs using the new async await and using Threads.

Using async-await give you the benefit of doing IO bound asynchronous work while feeling like you're executing synchronously. The Task Parallel Library provides an easy way of scheduling work on dedicated threads, be them thread-pool threads or new threads, while allowing you to hook into the mechanism which schedule those units of work. I really see no advantage in using fibers today, with all the framework has to offer.

I think you should tell your main-developer to do some reading on multi-threaded and asynchronous IO work using the Task Parallel Library and async-await, respectively. I think it would make life easier for all of you.

Yuval Itzchakov
  • 146,575
  • 32
  • 257
  • 321
  • 1
    Thanks for the through explanation. I really appreciate it. I think one of the biggest issue with fibers is the lack of .Net support as you mentioned. – Alireza Noori Jul 04 '15 at 17:17
  • 5
    +1 One additional note: `he knows which thread a particular function has come from and even could access the variables higher in the stack.` - I interpret this to mean that fibers preserve their call stack when resuming, whereas async methods do not. I think overall async/await/TPL are easier to use and reason about, but I can see the call stack debugging argument against them. – Stephen Cleary Jul 05 '15 at 02:50