Understanding of runtime goroutine struct G & M

[Robert Sandra]

Hi all,

I am not sure if my understanding is correct:

According to my understanding so far, G is goroutine and one M corresponds to an OS thread, a number of goroutines can be related to one M, if one go routine is being blocked, its related M will also be blocked, and other goroutines related to this M will be automatically moved to other M so that they will not be blocked. Am I right? If yes, could anyone tell me the source codes related to this action (automatically move other goroutines to some other runnable M)?

Thanks,

robert

[Rémy Oudompheng]

Currently, goroutines are not particularly related to M's, except
running goroutines and special cases.
A M that executes Go code cannot be blocked during operation.
Goroutines wait in a separate entity called Sched (runtime·sched).

Code for managing goroutines is essentially in proc.c only.

Rémy.

[Robert Sandra]

Thanks for the answer.

However, Go-FAQ said the follows: (http://golang.org/doc/go_faq.html#goroutines)

Goroutines are part of making concurrency easy to use. The idea, which has been around for a while, is to multiplex independently executing functions—coroutines—onto a set of threads. When a coroutine blocks, such as by calling a blocking system call, the run-time automatically moves other coroutines on the same operating system thread to a different, runnable thread so they won't be blocked.

I think the coroutine here is right a goroutine, right? 

[Jesse McNelis]

On Jan 8, 2013 6:32 PM, "Robert Sandra" <robert.s...@gmail.com> wrote:
>
> Goroutines are part of making concurrency easy to use. The idea, which has been around for a while, is to multiplex independently executing functions—coroutines—onto a set of threads. When a coroutine blocks, such as by calling a blocking system call, the run-time automatically moves other coroutines on the same operating system thread to a different, runnable thread so they won't be blocked.
>
> I think the coroutine here is right a goroutine, right? 
>

A goroutine can block without blocking the underlying thread eg. Waiting on a sync.muted or channel operation. But syscalls have to block the thread. So any goroutines that make syscalls will block their thread and other go routines will have to be run on a different thread.

[Ian Lance Taylor]

On Mon, Jan 7, 2013 at 11:32 PM, Robert Sandra
<robert.s...@gmail.com> wrote:
> Thanks for the answer.
>
> However, Go-FAQ said the follows:
> (http://golang.org/doc/go_faq.html#goroutines)
>
> Goroutines are part of making concurrency easy to use. The idea, which has
> been around for a while, is to multiplex independently executing
> functions—coroutines—onto a set of threads. When a coroutine blocks, such as
> by calling a blocking system call, the run-time automatically moves other
> coroutines on the same operating system thread to a different, runnable
> thread so they won't be blocked.
>
> I think the coroutine here is right a goroutine, right?

Yes, but don't take this description too literally. That is a way to
think about what happens and it is accurate as far as it goes.
However, as Rémy says, in the current implementation there is no
specific association of G and M structures. There is a single queue
of G structures that are ready to run, and each M picks one when it is
ready to run a G.

Ian

> On Tuesday, January 8, 2013 2:20:40 AM UTC-5, Rémy Oudompheng wrote:
>>
>> On 2013/1/8 Robert Sandra <robert.s...@gmail.com> wrote:
>> > Hi all,
>> >
>> > I am not sure if my understanding is correct:
>> >
>> > According to my understanding so far, G is goroutine and one M
>> > corresponds
>> > to an OS thread, a number of goroutines can be related to one M, if one
>> > go
>> > routine is being blocked, its related M will also be blocked, and other
>> > goroutines related to this M will be automatically moved to other M so
>> > that
>> > they will not be blocked. Am I right? If yes, could anyone tell me the
>> > source codes related to this action (automatically move other goroutines
>> > to
>> > some other runnable M)?
>>
>> Currently, goroutines are not particularly related to M's, except
>> running goroutines and special cases.
>> A M that executes Go code cannot be blocked during operation.
>> Goroutines wait in a separate entity called Sched (runtime·sched).
>>
>> Code for managing goroutines is essentially in proc.c only.
>>
>> Rémy.
>

> --
>
>

[Robert Sandra]

I re-check the following code in function runtime.entersyscall() : (http://golang.org/src/pkg/runtime/proc.c?#L974). 

It looks like what you and Jesse said: when the current running goroutine enters a syscall, the sche checks is there is any other goroutine waiting to run, if yes, func matchmg() is called to re-arrange currently waiting goroutines to other runnable threads. Is my understanding correct? Thank you!

schedlock();
   975		v = runtime·atomicload(&runtime·sched.atomic);
   976		if(atomic_gwaiting(v)) {
   977			matchmg();
   978			v = runtime·atomicload(&runtime·sched.atomic);
   979		}