As reported in TSAN0005 in #153852, there is a harmless data race in decimal's hash calculation. On a no-GIL build, two threads hashing the same decimal object for the first time concurrently produce a data race on self->hash. Fortunately, this is harmless because it is value-benign—both threads compute the exact same hash value. However, it is indeed an unsynchronized read-then-write, and ThreadSanitizer will report this issue.

A similar thing occurs in Unicode's hash calculation, which also uses a caching mechanism similar to decimal. In PR #134892, @colesbury mentioned:

Hash can be computed and assigned concurrently so to avoid a data race in free-threaded build:
#ifdef Py_GIL_DISABLED
return _Py_atomic_load_ssize_relaxed(&_PyASCIIObject_CAST(op)->hash);

Perhaps decimal could adopt the same approach here. But of course, since this potential data race is value-benign, I'm totally OK if we just leave this as is.

Reproduce:

• ./configure --disable-gil --with-thread-sanitizer
• make -j
• TSAN_OPTIONS="halt_on_error=1 symbolize=1 history_size=4" ./python repro_dec_hash.py
• repro_dec_hash.py

• Issue: Free-threading data races in CPython: 15 findings (9 new + 6 residual of existing FT work) #153852