Base.gensym() not always unique over threads,

[oxinabox]

Base,gensym() should always return a unique result.
I got currious as to if it did, when having multiple threads.
Answer: Mostly.

MVE:

julia> function tt2()
           ret = Vector{Symbol}(10)
           Base.Threads.@threads for ii in 1:10
                 ret[ii] = Base.gensym()
           end
           ret
       end
tt2 (generic function with 1 method)

julia> tt2()
10-element Array{Symbol,1}:
 Symbol("##271")
 Symbol("##273")
 Symbol("##275")
 Symbol("##271")
 Symbol("##273")
 Symbol("##271")
 Symbol("##276")
 Symbol("##278")
 Symbol("##273")
 Symbol("##277")

We can see that ##271 and #273 occurs multiple times.

• If I call tt2() a second time, it seems to always be unique.
• If I declare a new method tt3() is seems like it can occur on the first use of that

I guess this is some play with codegen.
Easy solution would be to append the generating threadid() whenever a symbol is generated.
But this might be a symptom of a deeper issue, so.

This is with:

julia> Base.Threads.nthreads()
10

julia> versioninfo()
Julia Version 0.5.0-rc0+150
Commit 389dc1c (2016-08-03 04:22 UTC)
Platform Info:
  System: Linux (x86_64-linux-gnu)
  CPU: AMD Opteron 63xx class CPU
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Piledriver)
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.7.1 (ORCJIT, bdver2)

[yuyichao]

Ref #16479 6eef572#commitcomment-10112067

The thread safety of gensym is a trivial issue. However, last time I looked at this when scanning all the gv's in the C code, the

    jl_set_t_uid_ctr(uid_ctr);
    jl_set_gs_ctr(gs_ctr);

logic in dump.c seems a little weird since it doesn't handle package precompilation and I'm not sure if it's necessary (at least the gensym one)

[oxinabox]

I just checked and this is still present in 0.6.1.
I've not checked master.