Benefits of runtime.LockOSThread in Golang

Question

Golang supports LockOSThread() to make current goroutine exclusively tied to current OS thread, and it can also UnlockOSThread().

Are there any use cases that benefit from this feature?

Answer 1

With the Go threading model, calls to C code, assembler code, or blocking system calls occur in the same thread as the calling Go code, which is managed by the Go runtime scheduler.

The os.LockOSThread() mechanism is mostly useful when Go has to interface with some foreign library (a C library for instance). It guarantees that several successive calls to this library will be done in the same thread.

This is interesting in several situations:

• a number of graphic libraries (OS X Cocoa, OpenGL, SDL, ...) require all the calls to be done on a specific thread (or the main thread in some cases).

• some foreign libraries are based on thread local storage (TLS) facilities. They store some context in a data structure attached to the thread. Or some functions of the API provide results whose memory lifecycle is attached to the thread. This concept is used in both Windows and Unix-like systems. A typical example is the errno global variable commonly used in C libraries to store error codes. On systems supporting multi-threading, errno is generally defined as a thread-local variable.

• more generally, some foreign libraries may use a thread identifier to index/manage internal resources.

Answer 2

runtime.LockOsThread it is usually used for calling C code that requires running in the main thread, like in graphics libraries.

Go Wiki page about LockOsThread and an example on how to use it.

Google groups discussion about the use of LockOsThread in SDL.

Answer 3

As mentioned here, What runtime.LockOSThread does is prevent any other goroutine from running on the same thread.
But note that Go 1.10 (Q1 2018) will change its usage a bit:

Because one common use of LockOSThread and UnlockOSThread is to allow Go code to reliably modify thread-local state (for example, Linux or Plan 9 name spaces), the runtime now treats locked threads as unsuitable for reuse or for creating new threads.

The behavior of nested calls to LockOSThread and UnlockOSThread has changed. These functions control whether a goroutine is locked to a specific operating system thread, so that the goroutine only runs on that thread, and the thread only runs that goroutine.

Previously, calling LockOSThread more than once in a row was equivalent to calling it once, and a single UnlockOSThread always unlocked the thread.

Now, the calls nest: if LockOSThread is called multiple times, UnlockOSThread must be called the same number of times in order to unlock the thread.