Asynchronicity in D

Steven Schveighoffer schveiguy at yahoo.com
Thu Mar 31 12:03:13 PDT 2011


On Thu, 31 Mar 2011 14:48:13 -0400, dsimcha <dsimcha at yahoo.com> wrote:

> == Quote from Andrej Mitrovic (andrej.mitrovich at gmail.com)'s article
>> Are fibers really better/faster than threads? I've heard rumors that
>> they perform exactly the same, and that there's no benefit of using
>> fibers over threads. Is that true?
>
> Here are some key differences between fibers (as currently implemented in
> core.thread; I have no idea how this applies to the general case in other
> languages) and threads:
>
> 1.  Fibers can't be used to implement parallelism.  If you have N > 1  
> fibers
> running on one hardware thread, your code will only use a single core.
>
> 2.  Fibers use cooperative concurrency, threads use preemptive  
> concurrency.  This
> means three things:
>
>     a.  It's the programmer's responsibility to determine how execution  
> time is
> split between a group of fibers, not the OS's.
>
>     b.  If one fiber goes into an endless loop, all fibers executing on  
> that
> thread will hang.
>
>     c.  Getting concurrency issues right is easier, since fibers can't be
> implicitly pre-empted by other fibers in the middle of some operation.   
> All
> context switches are explicit, and as mentioned there is no true  
> parallelism.
>
> 3.  Fibers are implemented in userland, and context switches are a lot  
> cheaper
> (IIRC an order of magnitude or more, on the order of 100 clock cycles  
> for fibers
> vs. 1000 for OS threads).

4. often there is an OS limit on how many threads a process can create.   
There is no such limit on fibers (only memory).  Using fibers can increase  
the number of simultaneous tasks that can be run by quite a bit.

-Steve


More information about the Digitalmars-d mailing list