[go-nuts] Goroutines vs. Threads vs. Processes

[John]

Hello all,

Although operating system programming and architecture aren't my
expertise within my research interests, from what I understand
(correct me if I'm wrong):

PROCESSES run in their own independent address space.

THREADS share address space with other threads...

So, here's the question... I know that Goroutines are the construct
within Go that allow for parallelization, but the definitions I've
seen given around the Go documentation sound an awful lot like
threads... so why does this documentation still insist that they
aren't the same as threads?

Thanks,

John


--
Subscription settings: http://groups.google.com/group/golang-nuts/subscribe?hl=en

[Russ Cox]

> PROCESSES run in their own independent address space.
>
> THREADS share address space with other threads...

This is a popular split but hardly the only definition
of those terms. One reason we use the name goroutine
is to avoid preconceptions about what those terms mean.
For many people threads also connotes management by
the operating system, while goroutines are managed first
by the Go runtime.

Russ

[Jessta]

On Tue, Apr 27, 2010 at 12:36 PM, John <gin...@gmail.com> wrote:
> Hello all,
>
> Although operating system programming and architecture aren't my
> expertise within my research interests, from what I understand
> (correct me if I'm wrong):
>
> PROCESSES run in their own independent address space.
>
> THREADS share address space with other threads...
>

Threads can be Real Threads, i.e What the CPU can be doing at one
time. (mostly more cores==more threads)
Threads can also refer to an operating system (pthreads) thread that
is scheduled on the CPU Real Threads like a process is and can be
pre-empted.

Co-routines(co-threads, sometimes these are also called threads) are
cooperative multi-tasking, one co-routine runs until it yields
control, it's state is saved and the program jumps to another
co-routine until that one yields etc.

A go-routine is a co-routine running on an operating system thread.
But they can be moved between operating system threads if needed.(eg.
when an operating system thread is going to be blocked by an syscall
made by one of the go-routines you can move the other go-routines
running on that operating system thread to another thread so they can
keep running)

wikipedia can provide more information.

- jessta
--
=====================
http://jessta.id.au

[Carl]

Some additional questions on Goroutines, I don't know if there is
already a document answering this somewhere. The answers would make
good material for the FAQ.

Given that an application makes heavy use of Goroutines:

How are the Goroutines specifically mapped to operating system
threads?

From a performance perspective: what will happen when Goroutines are
moved to another thread to avoid blocking?

Will there be a difference in the Goroutine/Thread mapping on specific
Operating Systems?

Will there be a difference on 32-bit versus 64-bit, also in the number
of mappable Goroutines (scalability)?

Is the Threading Model of some Operating Systems implementation better
than others with respect to projected Goroutines performance?

When actually is Context-Switching expected when using Go-routines?

In what scenarios will the performance of Goroutines likely be
performance-impacted because of context-switching?

Will there be performance increases with increasing the number of
cores per Processor?

Will there be performance increases with the number of native Hardware
Threads per Core?