You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
go version go1.8.3 windows/amd64
What operating system and processor architecture are you using (go env)?
set GOARCH=amd64
set GOBIN=
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=C:\Users\ifilippo\go
set GORACE=
set GOROOT=C:\Users\ifilippo\Desktop\go
set GOTOOLDIR=C:\Users\ifilippo\Desktop\go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0
set CXX=g++
set CGO_ENABLED=1
set PKG_CONFIG=pkg-config
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
What did you do?
I compile the following reproducer, which contains LockOSThread calls for two goroutines.
package main
import (
"runtime"
"os"
"runtime/trace"
"time"
)
func main() {
f, err := os.Create("trace.out")
if err != nil {
panic(err)
}
defer f.Close()
err = trace.Start(f)
if err != nil {
panic(err)
}
defer trace.Stop()
go func() {
runtime.LockOSThread()
heavyFunc1()
}()
go func() {
runtime.LockOSThread()
heavyFunc2()
}()
time.Sleep(1 * time.Second)
}
func heavyFunc1() {
for {
for i := 0; i < 10000; i++ {}
runtime.Gosched()
}
}
func heavyFunc2() {
for {
for i := 0; i < 10000; i++ {}
runtime.Gosched()
}
}
What did you expect to see?
After using "go tool trace trace.out" I expect to see that each proc is used by only one of two goroutines
What did you see instead?
I see that both goroutines use both Procs without any locking goroutine to proc.
Is it my misunderstanding of LockOSThread documentation or go tool trace documentation? Or is it a bug?
The text was updated successfully, but these errors were encountered:
odeke-em
changed the title
Unexpected result of "LockOSThread" call shown inside "go tool trace"
runtime/trace: unexpected result of LockOSThread call shown
Jun 29, 2017
@ifilippov, the "proc" lines shown in the execution trace are not OS threads. Rather, you can think of them as tokens the scheduler uses internally to give threads the right to execute Go code (which is why there are exactly GOMAXPROCS of them, while there can be any number of OS threads). In your case, your goroutines are staying on the same OS threads, but are bouncing these tokens back and forth as the goroutines reschedule.
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version
)?go version go1.8.3 windows/amd64
What operating system and processor architecture are you using (
go env
)?set GOARCH=amd64
set GOBIN=
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=C:\Users\ifilippo\go
set GORACE=
set GOROOT=C:\Users\ifilippo\Desktop\go
set GOTOOLDIR=C:\Users\ifilippo\Desktop\go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0
set CXX=g++
set CGO_ENABLED=1
set PKG_CONFIG=pkg-config
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
What did you do?
I compile the following reproducer, which contains LockOSThread calls for two goroutines.
package main
import (
"runtime"
"os"
"runtime/trace"
"time"
)
func main() {
f, err := os.Create("trace.out")
if err != nil {
panic(err)
}
defer f.Close()
err = trace.Start(f)
if err != nil {
panic(err)
}
defer trace.Stop()
go func() {
runtime.LockOSThread()
heavyFunc1()
}()
go func() {
runtime.LockOSThread()
heavyFunc2()
}()
time.Sleep(1 * time.Second)
}
func heavyFunc1() {
for {
for i := 0; i < 10000; i++ {}
runtime.Gosched()
}
}
func heavyFunc2() {
for {
for i := 0; i < 10000; i++ {}
runtime.Gosched()
}
}
What did you expect to see?
After using "go tool trace trace.out" I expect to see that each proc is used by only one of two goroutines
What did you see instead?
I see that both goroutines use both Procs without any locking goroutine to proc.
Is it my misunderstanding of LockOSThread documentation or go tool trace documentation? Or is it a bug?
The text was updated successfully, but these errors were encountered: