Re: [go-nuts] About runtime.globrunqput/globrunqputhead

2016-08-31 Thread Ian Lance Taylor
On Wed, Aug 31, 2016 at 7:54 PM, Lin Hao  wrote:
>
> I mean, sched.midle is a single linked list, but its mode of operation is
> different from sched.runqhead/runqtail, why? (or, Why they used different
> structure?)

The midle list is a list of M's that aren't doing anything.  It
doesn't matter which of them we use when we need one.  They weren't
doing anything anyhow.  So we just add M's on the front of the list
and remove them from the front of the list.

The runqhead/runqtail list is a list of G's that are waiting to run.
The G's on the list have work to do.  If we added G's on the front and
removed them from the front, then the one at the end would not run for
a very long time.  So for runqhead/runqtail we add them at the end and
remove them from the front.  That way every G on the list gets a fair
chance to run.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] About runtime.globrunqput/globrunqputhead

2016-08-31 Thread Lin Hao
Sorry, I haven't expressed clearly. I didn't suggest anything, just
wondering, so I want to ask about it.

I mean, sched.midle is a single linked list, but its mode of operation is
different from sched.runqhead/runqtail, why? (or, Why they used different
structure?)

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] About runtime.globrunqput/globrunqputhead

2016-08-31 Thread Ian Lance Taylor
On Tue, Aug 30, 2016 at 10:19 PM, Lin Hao  wrote:

>
> I'm reading the runtime code, and there are some questions, as shown below:
>
> func globrunqput(gp *g) {
> gp.schedlink = 0
> if sched.runqtail != 0 {
> sched.runqtail.ptr().schedlink.set(gp)// My question: why?
>
> // I feel should be gp.schedlink.set(sched.runqtail.ptr()) .
>
> // So, the chain is: sched.runqtail => old sched.runqtail.
>
> // I don't know if it's right (like sched.midle, single linked list).
>


To be honest I don't understand your suggestion.  The singly-linked list
starts at sched.runqhead, goes through the schedlink pointers of each G on
the list, and ends at sched.runqtail.  Caling
gp.schedlink.set(sched.runqtail.ptr()) won't put gp on the list.



> } else {
> sched.runqhead.set(gp)// My question: why?
>
> // Set here the head, and then set the tail.
>

That is exactly what this code does: sets the head, and then the next line
sets the fail.


> }
> sched.runqtail.set(gp)
> sched.runqsize++
> }
>
> func globrunqputhead(gp *g) {
> gp.schedlink = sched.runqhead
> sched.runqhead.set(gp)
> if sched.runqtail == 0 {
> sched.runqtail.set(gp)// My question: why?
>
> // Set the head, and then set the tail in here.
> }
> sched.runqsize++
> }
>
>
> Who can answer my question? I'm overwhelmed with gratitude.
>

I think you need to express your questions more clearly, as right now I
don't understand them.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.