Goroutines / Threads / Fibers

[jonatha...@gmail.com]

Good day everyone. I have a few questions I was hoping to get answered if anyone could take the time.

I have not taken the plunge in to working with Golang just yet, as I'm more of a C fanatic, but I have a colleague / old friend that has been an avid Go follower since its first release. He and I both seem to have a little bit of a confusion regarding threads, fibers and Goroutines, along with Go's usage of threading/fiber methodology in terms of the routines. 

As I understand it, a fiber would be a thread created by a thread and managed by its created thread... Meaning, the kernel would essentially still see the thread as, well, a thread. The confusion comes in to play where my associate insists that Goroutines are essentially "fibers", and the OS does not see them as threads. However, I see Goroutines as being more closely related to coroutines... Thus, not actually be "fibers" or "threads." 

His answer to try and clarify the behavior of Go's "fibers" being invisible to the kernel as a "thread" is as follows:

"Threads are sometimes implemented in userspace libraries, thus called user threads. The kernel is unaware of them, so they are managed and scheduled in userspace. Some implementations base their user threads on top of several kernel threads, to benefit from multi-processor machines (M:N model). In this article the term "thread" (without kernel or user qualifier) defaults to referring to kernel threads. User threads as implemented by virtual machines are also called green threads. User threads are generally fast to create and manage, but cannot take advantage of multithreading or multiprocessing, and will get blocked if all of their associated kernel threads get blocked even if there are some user threads that are ready to run.

Fibers are an even lighter unit of scheduling which are cooperatively scheduled: a running fiber must explicitly "yield" to allow another fiber to run, which makes their implementation much easier than kernel or user threads. A fiber can be scheduled to run in any thread in the same process. This permits applications to gain performance improvements by managing scheduling themselves, instead of relying on the kernel scheduler (which may not be tuned for the application). Parallel programming environments such as OpenMP typically implement their tasks through fibers. Closely related to fibers are coroutines, with the distinction being that coroutines are a language-level construct, while fibers are a system-level construct."

I'm hoping someone here can give me a better answer and description of:

1) Threading / Fiber concept

2) Goroutines and their association with the terminology of "fibers"

Thank you in advance.

[Ian Lance Taylor]

Terms like "fibers" are not well defined, at least not as far as I
know. Your definition of "fiber" above is "a fiber would be a thread
created by a thread and managed by its created thread." Given that
definition of fiber, goroutines are definitely not fibers. On the
other hand, given the definition of "fiber" at
https://en.wikipedia.org/wiki/Fiber_(computer_science) , then
goroutines pretty much are fibers (or coroutines), except that the
cooperative multitasking is inserted by the compiler, not explicitly
written by the Go programmer.

Also it's worth noting that the Go runtime will multiplex goroutines
onto multiple threads, so a single goroutine can be executed on many
different threads during its lifetime.

Ian

[hawtp...@email.com]

1) the core difference between fibers and threads is scheduling - cooperative vs preemptive. The rest is just rhetorical CS.
2) goroutines and fibers are cooperative with respect to their environments. fibers have generally been viewed as an operating system level construct, while goroutines are a construct of the golang environment.

However I disagree with a preceding post that likens coroutines to goroutines. The only aspect shared is scheduling. goroutines do not expose machinery to carry state - suspend to a state and resume to a state.

[Jesse McNelis]

On Mon, Nov 16, 2015 at 2:44 PM, <hawtp...@email.com> wrote:
> However I disagree with a preceding post that likens coroutines to
> goroutines. The only aspect shared is scheduling. goroutines do not expose
> machinery to carry state - suspend to a state and resume to a state.

That machinery is channels.

[hawtp...@email.com]

the two are separate constructs of the language. its not the same. take goroutines for what they are worth - constructs for cooperative multitasking for the golang environment. nothing more. yea, other language features could be use to create similar behavior, but i wanted to be clear that goroutines are not coroutines.

[Russel Winder]

Jonathan,

The language of threads and fibres does not really work well with Go,
or any other language with a structured concurrency and parallelism
model. These terms are only meaningful in low-level languages where the
programmer is exposed to them explicitly.

Languages with structured concurrency and parallelism models are
invariably based on a thread pool (which should be opaque to the
programmer) and tasks that are worked on inside the pool. Go's
goroutines are tasks that are worked on by a thread pool. Each task
should be what would traditionally be considered a single threaded
code.

 
> I'm hoping someone here can give me a better answer and description
> of:
>
> 1) Threading / Fiber concept

Threads used to be what fibres are now because threads moved from being
pure user space things to being kernel supported things. 

Rather than replicate a long explanation, you might want to get a CS
final year concurrency and parallelism text book, or for a quick
explanation the Wikipedia pages are not entirely wrong.

https://en.wikipedia.org/wiki/Thread_(computing)
https://en.wikipedia.org/wiki/Fiber_(computer_science)

> 2) Goroutines and their association with the terminology of "fibers"

Whatever previous email list threads (sic) have decided, and there have
been many threads on this topic, it is actually irrelevant whether
goroutines match any specific definition of fibre since they must be
thought of as tasks that are submitted to a thread pool for execution.

Hopefully this has helped even if it has not directly addressed the
questions asked.

--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel...@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder

[Konstantin Khomoutov]

On Sun, 15 Nov 2015 11:01:44 -0800 (PST)
jonatha...@gmail.com wrote:

[...]

> As I understand it, a fiber would be a thread created by a thread and
> managed by its created thread... Meaning, the kernel would
> essentially still see the thread as, well, a thread. The confusion
> comes in to play where my associate insists that Goroutines are
> essentially "fibers", and the OS does not see them as threads.
> However, I see Goroutines as being more closely related to
> coroutines... Thus, not actually be "fibers" or "threads."

[...]

Consider reading [1].
While it *is* outdated -- the Go scheduler has been improved,
especially visible in the 1.5 release -- the core idea of
"M:N multiplexing" is very well explained in this document, and
it has not changed (and probably won't because it's in the core
foundation of Go). In other words, that document tries to explain
in relatively non-hardcore terms the way goroutines work *without*
referring to different CS-related terms of which not all have
a universally agreed-upon meaning.

1. https://morsmachine.dk/go-scheduler

[Zlatko Calusic]

I found this blog article
http://dave.cheney.net/2015/08/08/performance-without-the-event-loop
very well written and informative. It covers more than just scheduler.

--
Zlatko

[Jesper Louis Andersen]

On Mon, Nov 16, 2015 at 2:41 AM, Ian Lance Taylor <ia...@golang.org> wrote:

Terms like "fibers" are not well defined, at least not as far as I
know.

Any low-level definition is susceptible to changes in hardware, and as the hardware changes, so will the definition in slight ways.

High-level definitions, like "delimited continuations" can capture the notion of what happens precisely. However, they succumb to the weakness of being far away from the machine, and hence tend to abstract away details which are important for understanding the ramifications in full.

Fibers have been used in many different ways. As synonyms for coroutines. As one-shot continuations (OCaml multicore). And slight variants thereof. Fibers also exist in naive set theory in mathematics, or as "fibered products" (Pullbacks) in Category Theory, but there is no coinciding definition with CS in this case[0].

[0] "Functor" is another common used word of which I know at least 4 different CS definitions: C++, Prolog, Haskell, and Standard ML. In the two latter cases, the definition coincides with the mathematical definition in very specific ways, whereas the two first definitions are as different as the concept of a fiber.

--

J.