<p>I was wondering if there is a way to "pin" goroutines to cores in go. An example scenario would be: I want to run X goroutines, where X is the number of cores and make sure that each goroutine is always scheduled on the same core. Maybe the scheduler already does that when X = num CPUs, I'm not sure?</p>
<hr/>**评论：**<br/><br/>thokk: <pre><p><a href="https://golang.org/pkg/runtime/#LockOSThread">https://golang.org/pkg/runtime/#LockOSThread</a></p></pre>Feribg: <pre><p>Thanks, do you happen to know if that's a default behavior if num of goroutines = num of worker threads?</p></pre>captncraig: <pre><p>It is not. If your goroutine blocks, nothing else will be scheduled on that OS thread. This will lead to new os threads being spawned, and will really hurt your performance if used improperly.</p>
<p>You really should not concern yourself with such details unless you have a really good reason to. </p></pre>Feribg: <pre><p>Why would new threads be created, I though the go runtime always allocates numcpu worker threads? So even if i block in the locked thread, it should just keep a static number of worker threads, right? My understanding is that this api call will basically convert a go routine to essentially a plain thread.</p></pre>captncraig: <pre><p>"Until the calling goroutine exits or calls UnlockOSThread, it will always execute in that thread, and no other goroutine can".</p>
<p>LockOSThread essentially takes the M out of the scheduler's pool of available os threads that it uses when it needs to run a G.</p>
<p>"The GOMAXPROCS variable limits the number of operating system threads that can execute user-level Go code simultaneously. There is no limit to the number of threads that can be blocked in system calls on behalf of Go code; those do not count against the GOMAXPROCS limit. This package's GOMAXPROCS function queries and changes the limit. "</p>
<p>That is not clear if locked goroutines count against this number, but it seems logical that they would not. If you have GOMAXPROCS=2 and 5 goroutines with locked os threads, you would have deadlock. New threads need to be spawned. </p>
<p>I'm gonna test now to confirm.</p></pre>captncraig: <pre><p>Confirmed with</p>
<pre><code>package main
import (
"fmt"
"runtime"
"time"
)
func main() {
for {
time.Sleep(time.Second)
go func() {
runtime.LockOSThread()
select {}
}()
}
select {}
}
</code></pre>
<p>and this incantation: </p>
<pre><code>NUM=`ps M <pid> | wc -l | xargs` && expr $NUM - 1
</code></pre>
<p>that number of threads does increase as more threads get locked.</p></pre>pierrrre: <pre><p>Don't do that.</p></pre>Feribg: <pre><p>My question is how to do it not should i or not :)</p></pre>Niriel: <pre><p>OpenGL does not work properly if called from different threads, it is mandatory to reserve one goroutine for opengl and lock it to a thread.</p></pre>boomshroom: <pre><p>That's why Vulkan is happening.</p></pre>pierrrre: <pre><p>He didn't say anything about OpenGL.</p></pre>Niriel: <pre><p>I know. Poster said "don't do that"; I gave one example to show that, sometimes, locking a goroutine to one thread is unavoidable. In these (hopefully rare) cases, we should be able to give some constructive advice.</p></pre>
