Fibers vs async await

Question

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 BackgroundWorker s to my multitasking operations. Today I was asking them why they used Fiber s 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 Fiber s vs using the new async await and using Thread s.

PS: We're using .Net 4.5

Answer 1

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.