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