www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Fibers

reply dsimcha <dsimcha yahoo.com> writes:
I noticed that, in D 2.20, we now have an implementation of fibers for D2.  I
understand the basic differences between a fiber and a thread (preemptive vs.
cooperative multitasking, threads can take advantage of multicore, fibers
can't).  However, from a more practical point of view, I've become curious,
what are fibers actually good for?  What can be done with fibers that either
can't be done at all or can't be done as efficiently/elegantly/safely with
threads?
Oct 21 2008
next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Wed, Oct 22, 2008 at 11:51 AM, dsimcha <dsimcha yahoo.com> wrote:
 I noticed that, in D 2.20, we now have an implementation of fibers for D2.  I
 understand the basic differences between a fiber and a thread (preemptive vs.
 cooperative multitasking, threads can take advantage of multicore, fibers
 can't).  However, from a more practical point of view, I've become curious,
 what are fibers actually good for?  What can be done with fibers that either
 can't be done at all or can't be done as efficiently/elegantly/safely with
 threads?

Oh, they're in core.thread! Huh. Very interesting. These are stack threads right? Check out the presentation from the D/Tango conference by Mikola -- it's very well done. http://petermodzelewski.blogspot.com/2008/10/tango-conference-2008-fibers-talk-video.html One thing I think they enable is a less hacky opApply. --bb
Oct 21 2008
next sibling parent Sean Kelly <sean invisibleduck.org> writes:
Bill Baxter wrote:
 On Wed, Oct 22, 2008 at 11:51 AM, dsimcha <dsimcha yahoo.com> wrote:
 I noticed that, in D 2.20, we now have an implementation of fibers for D2.  I
 understand the basic differences between a fiber and a thread (preemptive vs.
 cooperative multitasking, threads can take advantage of multicore, fibers
 can't).  However, from a more practical point of view, I've become curious,
 what are fibers actually good for?  What can be done with fibers that either
 can't be done at all or can't be done as efficiently/elegantly/safely with
 threads?

Oh, they're in core.thread! Huh. Very interesting.

Yup. Fibers are a part of the runtime because their memory must be exposed to the GC collection mechanism.
 These are stack threads right?

Yeah. I chose 'fiber' because it fits with the 'thread' terminology, but the implementation is based on Mik's StackThreads. At the moment, there are some issues with fibers using GDC, but hopefully they'll be sorted out by the time druntime supports GDC :-) Sean
Oct 21 2008
prev sibling parent reply Don <nospam nospam.com.au> writes:
Bill Baxter wrote:
 On Wed, Oct 22, 2008 at 11:51 AM, dsimcha <dsimcha yahoo.com> wrote:
 I noticed that, in D 2.20, we now have an implementation of fibers for D2.  I
 understand the basic differences between a fiber and a thread (preemptive vs.
 cooperative multitasking, threads can take advantage of multicore, fibers
 can't).  However, from a more practical point of view, I've become curious,
 what are fibers actually good for?  What can be done with fibers that either
 can't be done at all or can't be done as efficiently/elegantly/safely with
 threads?


 One thing I think they enable is a less hacky opApply.

What we need now is for someone to do a fiber-based tree implementation. OT: When I first read about fibers (in Microsoft docs) I found the terminology terribly confusing. Until I realized that "fiber" was the US spelling of "fibre", at which point the connection with threads became understandable. I still don't like the name, since OS threads aren't really made of "fibers". You're just switching stacks. One aspect of implementing threads is switching stacks. And that's the extent of the relationship, as far as I can tell.
Oct 22 2008
next sibling parent Sean Kelly <sean invisibleduck.org> writes:
Moritz Warning wrote:
 On Wed, 22 Oct 2008 11:47:14 +0200, Don wrote:
 
 Bill Baxter wrote:

 OT: When I first read about fibers (in Microsoft docs) I found the
 terminology terribly confusing. Until I realized that "fiber" was the US
 spelling of "fibre", at which point the connection with threads became
 understandable. I still don't like the name, since OS threads aren't
 really made of "fibers". You're just switching stacks. One aspect of
 implementing threads is switching stacks. And that's the extent of the
 relationship, as far as I can tell.

"Fiber" is also confusing to me (but I got used to it a bit). Why can't we call it StackThreads anyway?

"Fiber" was more meaningful to me. After all, every thread has a stack. Sean
Oct 22 2008
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
Don wrote
 
 OT: When I first read about fibers (in Microsoft docs) I found the 
 terminology terribly confusing. Until I realized that "fiber" was the US 
 spelling of "fibre", at which point the connection with threads became 
 understandable. I still don't like the name, since OS threads aren't 
 really made of "fibers". You're just switching stacks. One aspect of 
 implementing threads is switching stacks. And that's the extent of the 
 relationship, as far as I can tell.

I think the analogy fits in that a thread is made up of one or more fibers. The term "StackThread" didn't workfor me because all threads have a stack. I considered "ThreadContext" as well, but finally decided that "context" may be too loaded a term in this context (no pun intended). Sean
Oct 22 2008
prev sibling next sibling parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Tue, Oct 21, 2008 at 11:31 PM, Bill Baxter <wbaxter gmail.com> wrote:
 On Wed, Oct 22, 2008 at 11:51 AM, dsimcha <dsimcha yahoo.com> wrote:
 I noticed that, in D 2.20, we now have an implementation of fibers for D2.  I
 understand the basic differences between a fiber and a thread (preemptive vs.
 cooperative multitasking, threads can take advantage of multicore, fibers
 can't).  However, from a more practical point of view, I've become curious,
 what are fibers actually good for?  What can be done with fibers that either
 can't be done at all or can't be done as efficiently/elegantly/safely with
 threads?

Oh, they're in core.thread! Huh. Very interesting. These are stack threads right? Check out the presentation from the D/Tango conference by Mikola -- it's very well done. http://petermodzelewski.blogspot.com/2008/10/tango-conference-2008-fibers-talk-video.html One thing I think they enable is a less hacky opApply. --bb

And once it gets posted, the talk by Rick Richardson about DReactor is an example of fibers put to good use.
Oct 21 2008
prev sibling next sibling parent Moritz Warning <moritzwarning web.de> writes:
On Wed, 22 Oct 2008 11:47:14 +0200, Don wrote:

 Bill Baxter wrote:

 
 OT: When I first read about fibers (in Microsoft docs) I found the
 terminology terribly confusing. Until I realized that "fiber" was the US
 spelling of "fibre", at which point the connection with threads became
 understandable. I still don't like the name, since OS threads aren't
 really made of "fibers". You're just switching stacks. One aspect of
 implementing threads is switching stacks. And that's the extent of the
 relationship, as far as I can tell.

"Fiber" is also confusing to me (but I got used to it a bit). Why can't we call it StackThreads anyway?
Oct 22 2008
prev sibling next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Thu, Oct 23, 2008 at 3:52 AM, Sean Kelly <sean invisibleduck.org> wrote:
 Don wrote
 OT: When I first read about fibers (in Microsoft docs) I found the
 terminology terribly confusing. Until I realized that "fiber" was the US
 spelling of "fibre", at which point the connection with threads became
 understandable. I still don't like the name, since OS threads aren't really
 made of "fibers". You're just switching stacks. One aspect of implementing
 threads is switching stacks. And that's the extent of the relationship, as
 far as I can tell.

I think the analogy fits in that a thread is made up of one or more fibers. The term "StackThread" didn't workfor me because all threads have a stack. I considered "ThreadContext" as well, but finally decided that "context" may be too loaded a term in this context (no pun intended).

I don't have a problem with the name Fibers for this, I just get this feeling I've heard the term used somewhere to mean a lightweight hardware thread. But I could be wrong. Wikipedia seems to agree with the terminiology though: """ In this article, the term "thread" is used to refer to kernel threads, whereas "fiber" is used to refer to user threads. Fibers are cooperatively scheduled: a running fiber must explicitly "yield" to allow another fiber to run. A fiber can be scheduled to run in any thread in the same process. """ --- http://en.wikipedia.org/wiki/Multi-threading And here: """ Like threads, fibers share address space; where a distinction exists, it is that fibers use co-operative multitasking while threads use pre-emptive multitasking. Threads often depend on the kernel's thread scheduler to preempt a busy thread and resume another thread; fibers yield themselves to run another fiber while executing. """ ---- http://en.wikipedia.org/wiki/Fiber_(computer_science) And finally MS agrees with the terminology. The Windows API calls em Fibers too: http://msdn.microsoft.com/en-us/library/ms682661.aspx So it seems there's a fair amount of agreement out there about what to call these things. More than I initially realized. --bb
Oct 22 2008
prev sibling next sibling parent "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"dsimcha" <dsimcha yahoo.com> wrote in message 
news:gdm4ek$1qmh$1 digitalmars.com...
I noticed that, in D 2.20, we now have an implementation of fibers for D2. 
I
 understand the basic differences between a fiber and a thread (preemptive 
 vs.
 cooperative multitasking, threads can take advantage of multicore, fibers
 can't).  However, from a more practical point of view, I've become 
 curious,
 what are fibers actually good for?  What can be done with fibers that 
 either
 can't be done at all or can't be done as efficiently/elegantly/safely with
 threads?

I've used fibers for the following: I had to add compression support to some old file-IO API. The basic call I had to implement was void read(void*,size_t). The compression API I was using had a callback void process_data(void*, size_t). I used fibers to switch back and forth between the decompression and the reading. This prevented any memory allocation and saved an additional memcpy. This could also have been implemented using thread, but not without major synchronization. LPVOID io_fiber, comp_fiber; void* unpacked_data; size_t unpacked_size, unpacked_pos; //decompression callback static void process_data(void* data, size_t size) { unpacked_data = data; unpacked_size = size; unpacked_pos = 0; SwitchToFiber(io_fiber); // when we return we need more data } //IO api void read(void* data, size_t size) { while (true) { int data_available = unpacked_size - unpacked_pos; if (data_available) { int copy = min(data_available, size) memcpy(data, unpacked_data+unpacked_pos, copy ); unpacked_pos += copy; data += copy; size -= copy; } if (size == 0) break; SwitchToFiber(comp_fiber); // when we return we have new data } }
Oct 22 2008
prev sibling parent reply Graham St Jack <Graham.StJack internode.on.net> writes:
On Wed, 22 Oct 2008 02:51:00 +0000, dsimcha wrote:

 I noticed that, in D 2.20, we now have an implementation of fibers for
 D2.  I understand the basic differences between a fiber and a thread
 (preemptive vs. cooperative multitasking, threads can take advantage of
 multicore, fibers can't).  However, from a more practical point of view,
 I've become curious, what are fibers actually good for?  What can be
 done with fibers that either can't be done at all or can't be done as
 efficiently/elegantly/safely with threads?

I'm having a lot of success using fibers since I found out about them recently. Traditionally I use a lot of threads in my applications, usually for one of these reasons: * Desire to exploit multiple processors. * Need to keep complex state on the stack, usually for object I/O with things like sockets, pipes and serial ports. The last reason can be addressed with fibers, usually in conjunction with select, and I am finding that the resultant code complexity is a LOT lower because I don't have nearly as much thread-safety to worry about. The performance is a lot higher too because all those context switches have been replaced with fiber switches and select calls.
Oct 23 2008
next sibling parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Fri, Oct 24, 2008 at 2:21 AM, Graham St Jack
<Graham.StJack internode.on.net> wrote:
 The last reason can be addressed with fibers, usually in conjunction with
 select, and I am finding that the resultant code complexity is a LOT
 lower because I don't have nearly as much thread-safety to worry about.
 The performance is a lot higher too because all those context switches
 have been replaced with fiber switches and select calls.

You might take a look at DReactor then (http://dsource.org/projects/dreactor), since that's apparently what it's built around: using fibers and select calls while making the code _look_ like it's using blocking IO. The result is clean-looking but fast code. I have no idea if it's what you're after though :)
Oct 24 2008
prev sibling parent Graham St Jack <Graham.StJack internode.on.net> writes:
Thanks for the heads-up - I will look into it
Oct 26 2008