FibersNote: Due to enormous length of this article I decided to split it into parts.
When working with applications that utilize lots of threads and those threads arent particularry long running we can stumble upon a problem that we may lose most of the processing time for thread context switches, so it would be desirable to do all of the processing on a limited number of threads, usualy this can be done using a queue of delegates that each thread will process, but sometimes we cannot have that and still we would want to spawn units of work that behave like threads, enter Fibers.
A fiber logically is a unit of execution that behaves exacly like a thread but it's executing in the thread itself so one thread can "simulate" the execution of multiple threads, in most circumstancess fibers are not very beneficial as the cost of running then can be the same as threads and sometimes even higher, but this is not always true.
Fibers in actuality are different then threads as by design the user controls where and when to switch the context, and this must be done explicitly otherwise the context will never switch and other fibers will be stuck, manual switiching has some advantages thouh as the user can have a grater knowlede how to switch more effectivly.
.NET hasn't got fiber functionality, but Windows so we can eaisy do a wrapper class arround the unmanaged fiber api like so:
To prove that it actually works let's set up some sample code together: