Global Thread-local Storage feasibility and best Practices in Go

Question

I am a beginner in Golang, and I would like to implement something similar to the Mapped Diagnostic Context (MDC) in Java, which is achieved through thread-local storage, in Go. However, I find it hard to find information about global thread-local storage in Go online.

I have several questions:

Is it possible to create a kind of global thread-local storage for each goroutine in Go to store data and context?
Is attempting to implement global thread-local storage considered an anti-pattern in Go?
Is it recommended to replace the way of passing context by implementing global thread-local storage in Go?
Assuming in your choice, would you prefer to use the method of passing context or would you attempt to implement a thread-local storage to save and manage context?

I've found some references to this, but I can't come to a conclusion to decide whether to implement it or not.

See [Does Go have something like ThreadLocal from Java?](https://stackoverflow.com/q/31932945/5728991). — Charlie Tumahai, Jun 06 '23 at 06:16
1. No (goroutines are explicitely _designed_ to make thread-local storage impossible or at least hard). 2. Yes, absolutely. 3. Yes, No, It depends. Whether you pass this in a context.Context or in some other structure (e.g. a logger) doesn't matter much. A context.Context is considered a mechanism to carry cancelation, data is just an add on. 4. The first, thread local ugliness is shit from hell. — Volker, Jun 06 '23 at 06:28
One more: The name of the language is Go. Like its Java and not Javalang. — Volker, Jun 06 '23 at 06:28

Burak Serdar · Accepted Answer · 2023-06-07T15:53:39.680

There are several issues here, which usually happen when you try to emulate features of other languages in Go.

Goroutines are not threads. Goroutines do not have identities like threads do.
Context is to store request-scope state and data. It is not a replacement for thread-local storage.
If you think you need thread-local storage, then you might be misusing goroutines. Thread-local storage and thread pools are usually used when thread creation is costly, so you create them once and reuse them. Do not do that in Go unless goroutine initialization is costly. For most cases, just create a new goroutine and let it run to completion.
If you still think you need thread local storage, consider closures:

func f() {
   var i int
   go func() {
      // Here, use i as thread-local storage
   }()
}

If closures do not work, pass a struct around for thread-local storage

func f() {
  go func() {
     var t threadLocalData
     ...
     g(t)
     ...
  }{}
}

Global Thread-local Storage feasibility and best Practices in Go

1 Answers1