Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

runtime: golang scheduler is not preemptive - it's cooperative? #11462

Closed
GoranP opened this issue Jun 29, 2015 · 4 comments

Comments

Projects
None yet
5 participants
@GoranP
Copy link

commented Jun 29, 2015

If you run this code with only one go routine:

package main

import "fmt"
import "runtime"
import "time"

func cpuIntensive(p *int) {
  for i := 1; i <= 100000000000; i++ {
    *p = i
  }
}

func main() {
  runtime.GOMAXPROCS(1)

  x := 0
  go cpuIntensive(&x)

  time.Sleep(100 * time.Millisecond)

  // printed only after cpuIntensive is completely finished
  fmt.Printf("x = %d.\n", x)
}

Scheduler is paralized, and Printf is NOT printed after 100ms as expected, but after all job is done in cpuintensive() go routine.

But if programmer insert runtime.Gosched() in intensive for loop of routine, cooperative scheduler works fine.

Is this by design or are there plans to make Golang scheduler preemptive?

@davecheney

This comment has been minimized.

Copy link
Contributor

commented Jun 29, 2015

Is this by design or are there plans to make Golang scheduler preemptive?

It is by design. There are no plans to make the scheduler fully preemtive, in normal situations, this is not a problem.

@RLH

This comment has been minimized.

Copy link
Contributor

commented Jun 29, 2015

The traditional work around is to unroll the loop and add a Gosched. If
there are real world scenarios and available resources the compiler could
be taught how to do the transformation.

On Mon, Jun 29, 2015 at 7:19 AM, Dave Cheney notifications@github.com
wrote:

Is this by design or are there plans to make Golang scheduler preemptive?

It is by design. There are no plans to make the scheduler fully preemtive,
in normal situations, this is not a problem.


Reply to this email directly or view it on GitHub
#11462 (comment).

@aclements

This comment has been minimized.

Copy link
Member

commented Jun 29, 2015

@GoranP, you can think of the Go scheduler as being partially preemptive. It's by no means fully cooperative, since user code generally has no control over scheduling points, but it's also not able to preempt at arbitrary points. Currently, the general rule is that it can preempt at function calls, since at that point there's very little state to save or restore, which makes preemption very fast and dramatically simplifies some aspects of garbage collection. Your loop happens to contain none of these controlled preemption points, which is why the scheduler can't preempt it, but as @davecheney mentioned, this is fairly uncommon in real code (though by no means unheard of). We would like to detect loops like this and insert preemption points, but that work just hasn't happened yet. The issue for tracking that work (or, at least, the desire to do it :) is #10958.

Duplicate of #10958.

@aclements aclements closed this Jun 29, 2015

@mikioh mikioh changed the title golang scheduler is not preemptive - it's cooperative? runtime: golang scheduler is not preemptive - it's cooperative? Jun 30, 2015

@GoranP

This comment has been minimized.

Copy link
Author

commented Jun 30, 2015

Thx guys for clarification.

@golang golang locked and limited conversation to collaborators Jun 29, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.