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 reply 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
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 reply 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
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 "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 "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
parent reply "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
parent Graham St Jack <Graham.StJack internode.on.net> writes:
Thanks for the heads-up - I will look into it
Oct 26 2008