runtime.LockOSThread question

[Vasko Zdravevski]

Hi Gophers,

The docs for http://golang.org/pkg/runtime/#LockOSThread read as follows:

LockOSThread wires the calling goroutine to its current operating system thread. Until the calling goroutine exits or calls UnlockOSThread, it will always execute in that thread, and no other goroutine can.

I'm curious about the fragment I highlighted ... "and no other goroutine can" what? Can run in that thread? (Probably not the case with GOMAXPROCS=1) Maybe "no other goroutine can call LockOSThread on the same thread"?

So I searched "golang-nuts" and I found an older question on this, but the answer doesn't appear to be what I'm observing: https://groups.google.com/forum/#!searchin/golang-nuts/LockOSThread/golang-nuts/XFlbZ5_y1_k/48yjdI5zLM0J

Whatever the answer is, what I'm trying to find is a way to dedicate a thread to avoid situations where CPU intensive threads that don't perform blocking calls regularly don't hog the threads because of cooperative scheduler.

Here is an example: http://play.golang.org/p/tOyDjgxKYq

I thought 'LockOSThread' would guarantee my goroutine a thread to run that other goroutines couldn't hog, but apparently not the case. Any ideas on how to do that aside from the approach or guaranteeing that goroutines give up threads in reasonable intervals?

Env details:
go version devel +df37c4b Wed Sep 2 20:24:40 2015 +0000 darwin/amd64
GOMAXPROCS=NumCPU=8

Thanks,
Vasko.

[Ian Lance Taylor]

On Wed, Sep 2, 2015 at 5:25 PM, Vasko Zdravevski <vzdra...@gmail.com> wrote:
>
> The docs for http://golang.org/pkg/runtime/#LockOSThread read as follows:
>
> LockOSThread wires the calling goroutine to its current operating system
> thread. Until the calling goroutine exits or calls UnlockOSThread, it will
> always execute in that thread, and no other goroutine can.
>
> I'm curious about the fragment I highlighted ... "and no other goroutine
> can" what? Can run in that thread? (Probably not the case with GOMAXPROCS=1)
> Maybe "no other goroutine can call LockOSThread on the same thread"?

No other goroutine can execute in that thread.

> Whatever the answer is, what I'm trying to find is a way to dedicate a
> thread to avoid situations where CPU intensive threads that don't perform
> blocking calls regularly don't hog the threads because of cooperative
> scheduler.
>
> Here is an example: http://play.golang.org/p/tOyDjgxKYq
>
> I thought 'LockOSThread' would guarantee my goroutine a thread to run that
> other goroutines couldn't hog, but apparently not the case. Any ideas on how
> to do that aside from the approach or guaranteeing that goroutines give up
> threads in reasonable intervals?

Locking a goroutine to a thread does not exempt it from the GOMAXPROCS
setting. What you should do to make your program work better is not
bother about LockOSThread, but instead ensure that GOMAXPROCS is
larger than the number of CPU intensive threads.

Ian

[Vasko Zdravevski]

Thanks for the reply on this Ian!

I wrongly assumed LockOSThread would also lock my goroutine (G) to an OS Thread (M) and a proc slot (P).

After re-reading the "Scalable Go Scheduler Design Doc" (https://docs.google.com/document/d/1TTj4T2JO42uD5ID9e89oa0sLKhJYD0Y_kqxDv3I3XMw/edit), I found the "LockOSThread" section that explains it perfectly.

Thanks again Ian!