hi, can somebody explain to me exactly how fibers, microthreads,
protothreads and green threads work and what the differences are
between those?  thanks

"inhahe" <inhahe@numged.microcosmotalk.com> wrote in message 
news:4a677f1e$0$4944$9a6e19ea@unlimited.newshosting.com...
>
> hi, can somebody explain to me exactly how fibers, microthreads,
> protothreads and green threads work and what the differences are
> between those?  thanks
>

A "fiber" is a UNIX concept, so look into Unix and Linux documentation for 
that information.

Yes, a "thread" is a programming concept, but, as far as I am aware, it 
isn't typically "flavored" by giving it meaningless names.  You can get a 
hint about threads here:

http://en.wikipedia.org/wiki/Thread_(computer_science)

All of these issues relate to Operating Systems, so, perhaps you should 
enquire about them in a OS newsgroup?

Did you have a x86 Assembly Language question that you want to ask?

Nathan.

"Nathan Baker" <nathancbaker@munged.microcosmotalk.com> wrote:
>
>A "fiber" is a UNIX concept, so look into Unix and Linux documentation for 
>that information.

Fibers were introduced in Windows 2000, and MSDN has good information on
them.  Some Unix implementations had self-scheduled lightweight threads
prior to that, but I wasn't able to locate any references to the term
"fiber" for them.
-- 
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

On Jul 22, 5:21=A0pm, "Nathan Baker"
<nathancba...@munged.microcosmotalk.com> wrote:
> "inhahe" <inh...@numged.microcosmotalk.com> wrote in message
>
> news:4a677f1e$0$4944$9a6e19ea@unlimited.newshosting.com...
>
>
>
> > hi, can somebody explain to me exactly how fibers, microthreads,
> > protothreads and green threads work and what the differences are
> > between those? =A0thanks
>
> A "fiber" is a UNIX concept, so look into Unix and Linux documentation fo=
r
> that information.
>
> Yes, a "thread" is a programming concept, but, as far as I am aware, it
> isn't typically "flavored" by giving it meaningless names. =A0You can get=
 a
> hint about threads here:
>
> http://en.wikipedia.org/wiki/Thread_(computer_science)
>
> All of these issues relate to Operating Systems, so, perhaps you should
> enquire about them in a OS newsgroup?
>
> Did you have a x86 Assembly Language question that you want to ask?
>
> Nathan.

i know what threads are!
i'm asking particularly about microthreads, protothreads, fibers and
green threads.
it's a bit odd to assume they're meaningless names used to 'flavor'
the concept of threads just because you're not personally familiar
with them. these terms each have a wikipedia entry, speaking of
wikipedia.
wikipedia doesn't frame fibers as a particularly unix concept.  it
actually says they're used independently of the os, although the os
may provide facilitating functions, if i gathered right.
i'm not wondering about os apis for these concepts, since there are
none.
threads and these lightweight variants can only be implemented on the
level of assembly programming, so my question pertains to x86
programming.
but if this group is specifically about the x86 assembly language and
not about programming in it, then i can see why there'd be some
objection.  if so, i'd appreciate if someone points me to the
appropriate group related to x86 programming.
Thanks.

On Jul 23, 11:53=A0pm, Tim Roberts <t...@MUNGED.microcosmotalk.com>
wrote:
> Fibers were introduced in Windows 2000, and MSDN has good information on
> them.


Actually fibers were in WinNT.  IIRC in all versions of 4.0, and got
added via an SP in 3.51.  Since nothing prior to Win2K is supported,
most of the "minimum supported" comments in current MSDN libraries say
"Win2K."

Hi,

On Jul 23, 6:05 am, inhahe <inh...@numged.microcosmotalk.com> wrote:
> hi, can somebody explain to me exactly how fibers, microthreads,
> protothreads and green threads work and what the differences are
> between those?  thanks

As far as I can tell, green threads, light weight threads and fibers
are all different names for the exact same thing; and IMHO they all
suck (imagine 2 processes, where both processes have a high priority
light weight thread and a low priority light weight thread, and see if
you can figure out how to manage CPU time properly, so that all high
priority light weight threads are given priority over all low priority
light weight threads).

As far as I can tell microthreads are implemented in the CPU itself.
If this assumption is right, then 80x86 doesn't implement
microthreads. Instead most 80x86 CPUs do "out of order" execution,
which (to me) seems like a much more flexible way of achieving a
similar result - e.g. instruction dependencies (and register aliasing,
register renaming, etc) are tracked by the CPU itself, rather than
being explicit things a programmer/compiler needs to worry about,
which means different CPUs can have different characteristics (e.g.
different pipelines, etc) without needing different executable code to
take advantage of it.

As far as I can tell protothreads are half-way between light weight
threads and microthreads (or, based on what I said above, half-way
between "bad" and "not very good"). :)

Now that the formalities are out of the way; people who ask questions
typically have a reason for asking questions, and people that answer
questions can provide much better (more useful) answers if they know
what these reason are. What are your reason/s for asking?

I have a strange feeling the reason might be "my lecturer wanted
advice from about 30 people". In this case, most of the time the
lecturer wants you to rephrase whatever <insert name of reference
material/book used for course here> says, and in cases where this
reference material/book is "less than correct" a correct answer is the
wrong answer.



Cheers,

Brendan

On Jul 24, 4:41=A0am, Brendan <btrot...@MUNGED.microcosmotalk.com>
wrote:
> Hi,
>
> On Jul 23, 6:05 am, inhahe <inh...@numged.microcosmotalk.com> wrote:
>
> > hi, can somebody explain to me exactly how fibers, microthreads,
> > protothreads and green threads work and what the differences are
> > between those? =A0thanks
>
> As far as I can tell, green threads, light weight threads and fibers
> are all different names for the exact same thing; and IMHO they all
> suck (imagine 2 processes, where both processes have a high priority
> light weight thread and a low priority light weight thread, and see if
> you can figure out how to manage CPU time properly, so that all high
> priority light weight threads are given priority over all low priority
> light weight threads).
>
> As far as I can tell microthreads are implemented in the CPU itself.
> If this assumption is right, then 80x86 doesn't implement
> microthreads. Instead most 80x86 CPUs do "out of order" execution,
> which (to me) seems like a much more flexible way of achieving a
> similar result - e.g. instruction dependencies (and register aliasing,
> register renaming, etc) are tracked by the CPU itself, rather than
> being explicit things a programmer/compiler needs to worry about,
> which means different CPUs can have different characteristics (e.g.
> different pipelines, etc) without needing different executable code to
> take advantage of it.
>
> As far as I can tell protothreads are half-way between light weight
> threads and microthreads (or, based on what I said above, half-way
> between "bad" and "not very good"). :)
>
> Now that the formalities are out of the way; people who ask questions
> typically have a reason for asking questions, and people that answer
> questions can provide much better (more useful) answers if they know
> what these reason are. What are your reason/s for asking?
>
> I have a strange feeling the reason might be "my lecturer wanted
> advice from about 30 people". In this case, most of the time the
> lecturer wants you to rephrase whatever <insert name of reference
> material/book used for course here> says, and in cases where this
> reference material/book is "less than correct" a correct answer is the
> wrong answer.
>
> Cheers,
>
> Brendan

Oh, this has nothing to do with lecturing.  I'm not even signed up for
classes for this semester.  For my particular purposes, I don't need
to worry about thread priorities, so that part's fine.  (although,
just for the sake of argument, couldn't you schedule them the same way
the OS schedules normal threads?  i guess it's a little more
complicated because of cooperative multitasking, but just keep track
of how long things actually did run rather than pre-empt them..?)

I've done some reading about pipelining and out-of-order execution.
It's interesting, and yes, partially because of how it actually keeps
all that manipulation transparent to the programmer.  But, because it
is transparent to the programmer, I think it's a separate issue from
lightweight threads, which as i understand it, use certain features
of the cpu (so, i'm assuming, certain opcodes), but are still a thing
that programmers do.  For example, fibers in particular are used for
coroutines.  If fibers only existed within the CPU on a level
transparent to programmers, the programmer wouldn't be able to make
use of coroutines either.  Basically, I get the idea that lightweight
threads provide a much faster means of task switching and with much
less memory overhead, but aren't particularly implemented by existing
OS's, so must be done on the application level.

So basically, my question is how to do this on the application level.
I assume this must be done using assembly, because it must make use of
some sort of register pushing, popping, etc. functions.

In particular, I want to do this to create a chain of DSP filters.
Let's say that each filter processes 500 samples at a time, then
(cooperatively, of course) passes control of execution over to the
next filter.  I want the smaller task switching overhead of
lightweight threads, and since I'm just chaining (no sophisticated
scheduling) and my threads can be cooperative, I'm thinking that
lightweight threads are totally sufficient.

I'm not sure that fibers, protothreads and green threads are exactly
the same thing.  Their Wikipedia articles aren't even merged.  (they
do have wikipedia articles but they don't seem to convey enough
information for my needs, such as for example, how to do them..).  But
I think microthreads are in a somewhat different class and I guess
that's the basis for your comments on them being pretty much internal
CPU functions.  I don't think they're what I need, so my questions are
more limited to fiber, protothreads and green threads.

<robertwessel2@MUNGED.microcosmotalk.com> wrote in message 
news:4a697363$0$4939$9a6e19ea@unlimited.newshosting.com...
>
> On Jul 23, 11:53=A0pm, Tim Roberts <t...@MUNGED.microcosmotalk.com>
> wrote:
>> Fibers were introduced in Windows 2000, and MSDN has good information on
>> them.
>
>
> Actually fibers were in WinNT.  IIRC in all versions of 4.0, and got
> added via an SP in 3.51.  Since nothing prior to Win2K is supported,
> most of the "minimum supported" comments in current MSDN libraries say
> "Win2K."

My reference material says that UNIX server applications were written to 
operate in a single thread but still serve multiple clients.  The developers 
accomplished this feat by constructing a simulated-threading architecture 
library.  Windows NT 3.51 service pack 3 introduced fibers to ease the 
porting of such applications to the Windows platform.

Nathan.

"inhahe" <inhahe@MUNGED.microcosmotalk.com> wrote in message 
news:4a693e5d$0$4976$9a6e19ea@unlimited.newshosting.com...
>
>
> i'm not wondering about os apis for these concepts, since there are
> none.

They exist in the Win32 API.

> threads and these lightweight variants can only be implemented on the
> level of assembly programming, so my question pertains to x86
> programming.

All of these things can be implemented at the C and C++ level too.

> but if this group is specifically about the x86 assembly language and
> not about programming in it, then i can see why there'd be some
> objection.  if so, i'd appreciate if someone points me to the
> appropriate group related to x86 programming.

I stand corrected.  Here is a simple example (written in HLA) that 
demonstrates use of the Windows 'fiber' functions:

http://pastebin.com/m2f007cfc

Funny, I feel a little "cleaned out" now.  :)

Nathan.

On Jul 24, 9:42=A0pm, "Nathan Baker"
<nathancba...@munged.microcosmotalk.com> wrote:
> <robertwess...@MUNGED.microcosmotalk.com> wrote in message
>
> news:4a697363$0$4939$9a6e19ea@unlimited.newshosting.com...
>
>
>
> > On Jul 23, 11:53=3DA0pm, Tim Roberts <t...@MUNGED.microcosmotalk.com>
> > wrote:
> >> Fibers were introduced in Windows 2000, and MSDN has good information =
on
> >> them.
>
> > Actually fibers were in WinNT. =A0IIRC in all versions of 4.0, and got
> > added via an SP in 3.51. =A0Since nothing prior to Win2K is supported,
> > most of the "minimum supported" comments in current MSDN libraries say
> > "Win2K."
>
> My reference material says that UNIX server applications were written to
> operate in a single thread but still serve multiple clients. =A0The devel=
opers
> accomplished this feat by constructing a simulated-threading architecture
> library. =A0Windows NT 3.51 service pack 3 introduced fibers to ease the
> porting of such applications to the Windows platform.


Right, but coroutines as a concept are far older than Unix.

"inhahe" wrote:
[...]
> So basically, my question is how to do this on the application level.

Usually never, because 'modern' OS will do this for you and wont allow
user-code to fiddle with low-level task-switching even you may be able
to override some of the paranoid protection borders.

> I assume this must be done using assembly, because it must make use of
> some sort of register pushing, popping, etc. functions.

Sure, find all required details in the CPU-manuals
(ie: AMD64 Volume 1..5 and AMD 40555.pdf)
and then write you own Multi-core/-thread/-task OS....

> ..., so my questions are more limited to fiber, protothreads
> and green threads.

If you ask me, an older low-level-freak,
this things are just names for the attempt to describe how most
High-Level coders see and understand what a CPU may can do and
perhaps similar misunderstood like MultiTasking often were.
__
wolfgang

"inhahe" <inhahe@MUNGED.microcosmotalk.com> wrote in message
news:4a6a335e$0$4969$9a6e19ea@unlimited.newshosting.com...
>
> > On Jul 23, 6:05 am, inhahe <inh...@numged.microcosmotalk.com> wrote:
> >
> > > hi, can somebody explain to me exactly how fibers, microthreads,
> > > protothreads and green threads work and what the differences are
> > > between those? thanks
>
> I'm not sure that fibers, protothreads and green threads are exactly
> the same thing.  Their Wikipedia articles aren't even merged.  (they
> do have wikipedia articles but they don't seem to convey enough
> information for my needs, such as for example, how to do them..).  But
> I think microthreads are in a somewhat different class and I guess
> that's the basis for your comments on them being pretty much internal
> CPU functions.  I don't think they're what I need, so my questions are
> more limited to fiber, protothreads and green threads.

Well, I thought you were talking about carpet at first...  ;)   FYI, there
is a Wikipedia article for all of them:

http://en.wikipedia.org/wiki/Microthread
http://en.wikipedia.org/wiki/Fiber_(computer_science)
http://en.wikipedia.org/wiki/Green_thread
http://en.wikipedia.org/wiki/Protothreads


Since I'm unfamiliar with this, this is what I took away from Wikipedia
articles:

fiber - uses co-operative multitasking
thread - uses pre-emptive multitasking

protothreads - stackless, no local variables, non-preemptable
microthreads - small independent code fragments
greenthreads - schedulable threads implemented by a virtual machine without
using the host OS


As Wolfgang said, the OS typically decides what type of multitasking you'll
be using, i.e., threads or fibers, er... co-operative or pre-emptive.  Now,
does that mean you can't implement some of these or something really close
in functionality?  No.  I think you can come real close to some of them.
You may still be stuck using the host OS' method of multitasking though,
which likely has more overhead.  It seems that some of these by definition
have smaller, faster context-switch methods.

protothreads - To me, a single "protothread" seems very similar to a
procedure without arguments or returns in C, e.g., "void proc(void)".  The
procedure will be stackless, have no local variables, but without some
assembly to disable interrupts it'll be preemptable.  An assembly routine
that doesn't use a stack or have parameters or returns, should be similar
too.  The host OS may block your ability to enable/disable interrupts which
is needed to be non-preemptable.  If it does, you'll have to make each
indepedent of the others, or reentrant if duplicated.

microthreads - small code fragments which are different and independent of
each other, or fragments that are similar and reentrant should function as
microthreads.  Since you made them independent and/or reentrant, they call
all execute concurrently without problems.  The problem here is that you'll
likely have to use the host OSes mechanism for multitasking which won't be
as lean as a pure implementation.

greenthreads - write your own VM with a method for multitasking, threads,
context-switch, and scheduling


Rod Pemberton

Hi,

On Jul 25, 7:19 am, inhahe <inh...@MUNGED.microcosmotalk.com> wrote:
> In particular, I want to do this to create a chain of DSP filters.
> Let's say that each filter processes 500 samples at a time, then
> (cooperatively, of course) passes control of execution over to the
> next filter.  I want the smaller task switching overhead of
> lightweight threads, and since I'm just chaining (no sophisticated
> scheduling) and my threads can be cooperative, I'm thinking that
> lightweight threads are totally sufficient.

In this specific case, why do you need any kind of threads at all -
when one DSP filter passes control to the next DSP filter, what's
wrong with a "JMP" or "CALL" instruction?

To use more than one CPU, lightweight threads (and fibers,
protothreads, green threads and anything else that the OS's kernel
isn't aware of) on their own is not an option.

Note: It's possible to have many lightweight threads backed by several
real threads/CPUs, but I'm thinking that one thread per CPU is the
most you need, and you'd gain nothing by having the extra overhead of
lightweight threads on top of this.


Cheers,

Brendan

On Jul 25, 2:44=A0pm, Brendan <btrot...@munged.microcosmotalk.com>
wrote:
> Hi,
>
> On Jul 25, 7:19 am, inhahe <inh...@MUNGED.microcosmotalk.com> wrote:
>
> > In particular, I want to do this to create a chain of DSP filters.
> > Let's say that each filter processes 500 samples at a time, then
> > (cooperatively, of course) passes control of execution over to the
> > next filter. =A0I want the smaller task switching overhead of
> > lightweight threads, and since I'm just chaining (no sophisticated
> > scheduling) and my threads can be cooperative, I'm thinking that
> > lightweight threads are totally sufficient.
>
> In this specific case, why do you need any kind of threads at all -
> when one DSP filter passes control to the next DSP filter, what's
> wrong with a "JMP" or "CALL" instruction?

Basically the filters may need to keep track of local variables, i.e.
any filter that retains some sort of state, or at least that does this
inside of registers.  But I'm not sure I need lightweight threads
either.. maybe I should just have each filter execute the specified
number of samples and then push and pop everything that needs to be
stored.  But since I don't know specifically what cpu functions are
used for lightweight threads, i'm not sure if there's something i'd be
missing in that strategy (along the lines of efficiency).

I started reading the intel manuals to determine how lightweight
threads might be implemented, but I figured it might better to first
hit the asm forums, because otherwise it would be a lot of reading,
and after i'm done, i probably still wouldn't have a clue since the
cpu is pretty complicated and the manuals probably don't address this
issue directly.


>
> To use more than one CPU, lightweight threads (and fibers,
> protothreads, green threads and anything else that the OS's kernel
> isn't aware of) on their own is not an option.
>
> Note: It's possible to have many lightweight threads backed by several
> real threads/CPUs, but I'm thinking that one thread per CPU is the
> most you need, and you'd gain nothing by having the extra overhead of
> lightweight threads on top of this.
>

Basically I want to break up the filter chain so that a certain number
of filters are chained together on each core in lightweight threads
(or maybe just loops, jmps, pusha's, etc.) and then where the chain
crosses cores the scheduling is done on the normal OS thread level.
I.e., it's totally okay if my cooperative threads are pre-empted in
between by the OS.  That way I get the benefit of lightweight
switching except where needed to take advantage of multiple cores.

I don't think it defeats the purpose of preemptive multitasking is
done by the OS below the layer of my cooperative multitaskng because
there will be fewer OS threads that way than if I put one filter in
each thread (and i can't just use jmp's because state must be
remembered), and thus fewer more expensive task switches, and I will
also get the faster latency I need.  For example two lightweight
threads in a chain could process only 500 samples before the result is
sent to the soundcard, giving a minimum possible latency of 11
milliseconds, which is less than the time granularity of normal OS
task switching.  And if this is the only program running then this
task will get most of the CPU time so OS thread time granularity
shouldn't get in the way much.

So basically I'm just wondering what special opcodes are used for
lightweight threads -- or maybe more to the point, coroutines.
Perhaps going into stdlib.hhf or w.hhf and seeing what those fiber
switching and creating functions in that sample hla file do will give
me answers.

Thanks for the responses

On Jul 26, 8:58=A0pm, inhahe <inh...@MUNGED.microcosmotalk.com> wrote:
>
> So basically I'm just wondering what special opcodes are used for
> lightweight threads -- or maybe more to the point, coroutines.
> Perhaps going into stdlib.hhf or w.hhf and seeing what those fiber
> switching and creating functions in that sample hla file do will give
> me answers.
>

There is certainly nothing "special" about the opcodes.  These CPU
instructions are pretty common in every program no matter what the
task.

Have a look at the co-routine unit of the HLA Standard Library for an
example:

http://hla-stdlib.svn.sourceforge.net/viewvc/hla-stdlib/trunk/os_coroutines=
/

For details about how Microsoft implements the ??Thread and ??Fiber
functions you will need to Google for the source code for the Windows
OS.

Nathan.