www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Fibers, what for?

reply Patric Dexheimer <patric.dexheimer gmail.com> writes:
I learned about Fibers on D, and now i´m starting to read about 
it (Threads/Fibers/Coroutines) etc.
But when i try to make something usefull with it i just fail to 
see the real advantage over a normal structured programming 
without it.

Can someone show some code with usefull/unique/advantageous use 
of fibers?
Thanks in advance!
Jun 11 2016
parent reply Era Scarecrow <rtcvb32 yahoo.com> writes:
On Sunday, 12 June 2016 at 02:43:40 UTC, Patric Dexheimer wrote:

 I learned about Fibers on D, and now I´m starting to read about 
 it (Threads/Fibers/Coroutines) etc. But when I try to make 
 something usefull with it I just fail to see the real advantage 
 over a normal structured programming without it.

 Can someone show some code with usefull/unique/advantageous use 
 of fibers?
 Thanks in advance!


  Fibers since they use the same thread as what calls them, it 
doesn't seem like it would help much. However if there is a delay 
for something for some reason (IO, or putting a delay in the 
current logic for a little while) then (to my understanding) 
Fibers kicks in and lets you keep going.

  A big reason you would want Fibers is not to lose the time slot 
your code has for working, not because it makes the program 
slower, but if the OS switches to another process, when it 
returns you have cold data (not cached).

  So, assuming you have stuff to work on and you want to open a 
file too, you might do it like this.

   work(someargs); //work could be moved after the reading of 
content too...
   string content = readFile("Some file.txt");

  This will process work and then open the file. However while the 
file is opening it may be a while before the file fully opens, or 
can be read the physical IO (spinning disks waiting on the OS, 
other delays) may end up dropping your current time slot.

  A fiber on the other hand you would do it this way: (API is 
probably wrong, so don't rely on this example to actually compile)

   Fiber fiber = new Fiber();
   Fiber.run(work, someargs);
   string content = readFile("Some file.txt");

  Now when the blocking IO happens during opening or reading, the 
Fiber takes over and does some work in the background. If you 
recently worked on any data that remains hot (cached) and you get 
better performance as long as it's hot.

  To note I am still watching the recent DConf 2016 which sorta 
covers this, which is much better than my reply :P
Jun 11 2016
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 06/11/2016 07:58 PM, Era Scarecrow wrote:


  recent DConf 2016 which sorta covers this


For convenience, here's the link:

   http://www.ustream.tv/recorded/86352137/highlight/699197

However although I'm very biased :), I still like the following fiber 
explanation that emphasizes function call stack:

   http://ddili.org/ders/d.en/fibers.html

Ali
Jun 11 2016
parent reply chmike <christophe meessen.net> writes:
On Sunday, 12 June 2016 at 05:11:57 UTC, Ali Çehreli wrote:


 For convenience, here's the link:

   http://www.ustream.tv/recorded/86352137/highlight/699197


unfortunately iPads are not supported to view the video. :(

I see two major benefits of fibers overs threads.

Fibers don't need synchronization to access shared data. This 
removes the overhead of synchronization and simplifies 
"multitheaded" programming greatly.

The second benefit is that fibers have a much lower time cost of 
context switching. When a fiber yields the processor to another 
fiber, the switch is immediate and the other fiber can immediatly 
resume its task. With threads, you have to wait that the OS give 
the processor back to your process. This can take some time when 
there are many other threads competing for the processor. The 
performance difference is the most notable when the amount of 
work to do between switches is small.

Most popular and succesfull use for fibers is for asynchronous or 
event driven processing.
Jun 12 2016
parent reply Alex Parrill <initrd.gz gmail.com> writes:
On Sunday, 12 June 2016 at 08:38:03 UTC, chmike wrote:

 Fibers don't need synchronization to access shared data. This 
 removes the overhead of synchronization and simplifies 
 "multitheaded" programming greatly.


This is misleading. Any sort of cooperative system needs 
synchronization when two or more tasks try to access the same 
data, whether those "tasks" are OS threads, fibers, different 
machines on a network, etc.

Fibers do make it easier, as no task can run in parallel with the 
current one and switching tasks is done explicitly via yield, 
effectively giving the current fiber exclusive access to the 
entire program state in between yields. But if you need to hold 
onto a resource across a yield, you will need the usual set of 
concurrency primitives, like locks.

(A practical example: making a commit using the Node.js libgit 
bindings involves several asynchronous steps, during which other 
tasks may access it. If you don't want anyone else messing with 
the Git repo while you are making a commit, you must protect the 
repo with a lock.)

Also note that Vibe.d, the largest fiber-based framework D has to 
offer, is capable of running several coroutines in parallel on 
multiple threads, meaning you must use the same level of 
synchronization as if you were using threads.
Jun 12 2016
next sibling parent reply Patric Dexheimer <patric.dexheimer gmail.com> writes:
On Monday, 13 June 2016 at 00:57:11 UTC, Alex Parrill wrote:

 Also note that Vibe.d, the largest fiber-based framework D has 
 to offer, is capable of running several coroutines in parallel 
 on multiple threads, meaning you must use the same level of 
 synchronization as if you were using threads.


Vibe.d framework share the same fibers between threads?
Or each thread have his own fibers?
I was trying this(shared fibers) but it didnt work.
Jun 12 2016
parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 06/12/2016 07:19 PM, Patric Dexheimer wrote:

 On Monday, 13 June 2016 at 00:57:11 UTC, Alex Parrill wrote:

 Also note that Vibe.d, the largest fiber-based framework D has to
 offer, is capable of running several coroutines in parallel on
 multiple threads, meaning you must use the same level of
 synchronization as if you were using threads.


 Vibe.d framework share the same fibers between threads?
 Or each thread have his own fibers?
 I was trying this(shared fibers) but it didnt work.


D fibers don't (actually, can't) move between threads. Vibe.d uses 
regular D fibers, so it's true there as well.

The main reason why it's not currently possible is data being 
thread-local by default. If fibers could move, a fiber accessing a 
thread-local data would continue accessing the same data at the same 
address but it would be different data on that thread.

This huge thread has interesting discussions on not moving fibers 
between threads:

   http://forum.dlang.org/post/mf3hk7$1ucr$1 digitalmars.com

Ali
Jun 12 2016
prev sibling parent chmike <christophe meessen.net> writes:
On Monday, 13 June 2016 at 00:57:11 UTC, Alex Parrill wrote:

 This is misleading. Any sort of cooperative system needs 
 synchronization when two or more tasks try to access the same 
 data, whether those "tasks" are OS threads, fibers, different 
 machines on a network, etc.


That is true. Sorry. What I meant is that with fibers the yield 
is performed in well defined locations it could be in blocking 
calls like read() or write() or when yield is called.
For this reason it is simpler to synchronize access to shared 
ressources with fibers than with threads. It's thus POSSIBLE to 
write code that doesn't need synchronization even when shared 
ressources are used.

Note also that the synchronization mechanism can be much simpler 
and efficient than the one needed with threads.

With threads you MUST allways synchronize access to shared 
ressources and protect critical sections of your code, or use 
specially crafted none blocking data structures using atomic 
operations.
Jun 13 2016