hash-table failures on relaxed memory order machines

[Douglas Katzman]

(HASH-TABLE :SINGLE-ACCESSOR :PARALLEL-GC) fails often on ppc64, in a way that I have never observed on x86-64.

./parallel-exec.sh -j 2 --runs_per_test 4 gethash-concurrency.impure.lisp
...
Failing files:
(gethash-concurrency.impure 4 84902)

The error is:
oops: The assertion (EQ VAL I) failed with VAL = #<unbound>, I = 88. in #<THREAD "accessor" RUNNING {10025706BC}>
or similar, for different values of I.

One failure in 4 trials is not good for anyone who expects even single-reader safety.
I don't test threaded builds on other CPUs enough to know where else the failures are, but I'm near certain this is only on RMO architectures,
And if anything, I'd have expected the concurrent reader test to fail as well.

[Stas Boukarev (stassats)]

Never seen that on arm64 either, and ./parallel-exec.sh -j 3 --runs_per_test 100 gethash-concurrency.impure.lisp is successful.

[Douglas Katzman (dougk)]

Same root cause as lp#1959338