Re: Fibers, what for?
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.
Re: Fibers, what for?
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
Re: Fibers, what for?
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.
Re: Fibers, what for?
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.
Re: Fibers, what for?
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.
Re: Fibers, what for?
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
Re: Fibers, what for?
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
Fibers, what for?
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!
