Is uuid.NewV4() thread safe? about go.uuid HOT 2 CLOSED

I don't believe uuid.NewV4() is thread safe. here's the source for NewV4():

func (g *rfc4122Generator) NewV4() (UUID, error) {
	u := UUID{}
	if _, err := g.rand.Read(u[:]); err != nil {
		return Nil, err
	}
	u.SetVersion(V4)
	u.SetVariant(VariantRFC4122)

	return u, nil
}

the rfc4122Generator struct is global. the rand member (io.Reader) is not protected by any sort of mutex, and io.Readers just read from a raw byte buffer.

you could wrap NewV4() to be thread safe, something like:

var uuidGenerator sync.Mutex
func NewV4() (uuid.UUID, error) {
  uuidGenerator.Lock()
  defer uuidGenerator.Unlock()
  return uuid.NewV4()
}

although using goroutines to generate UUIDs, perhaps using channels to queue requests & responses is the more idiomatic go way.

from go.uuid.

Globals and thread-safety are only of concern if there are writes happening to the global (or more specifically, to some piece of shared data, globally-scoped-or-not) concurrently with reads. (Ie. a "global" or shared var that's read-only throughout run time after some initial writes at init time is fully benign.) Not seeing such a situation here: a never-EOF'ing read-only rand reader should be "safeish" to a first intuition to begin with. What sort of state might it have to protect, really? But to verify our first intuition, we check the linux/unix/bsd/plan9 impl and lookie, there is seemingly a mutex on the underlying /dev/rand-consuming io.Reader anyway! see https://golang.org/src/crypto/rand/rand_unix.go --- so another locking/sync on top of it would buy nothing (but cost extra).

Haven't checked the Win impl, but the stdlib authors should surely be consistent in the locking/synchronization semantics of impls across OSes here. Anyone concerned can skim over the sources just as easily as I demo'd above 😁

from go.uuid.