Potential race conditions in both C testfloat3 and Go rand number generators

[nadime15]

I am seeing inconsistent .quad values between compilations, even though I use fixed seeds. The issue are race conditions caused by multiple goroutines accessing the shared number generator in different orders and resets in between.

What I think is happening:
Multiple goroutines call (indirectly via main) testfloat3.InitF16() , and that function calls srand(2024). At the same time, Go’s genRandomData() calls rand.Seed(n).

Due to the parallelization of the loop with goroutines, these generators are reset and consumed simultaneously. The seeds are deterministic, but the access pattern is not, which leads to non deterministic sequences.

For context: I have customized the script to only test the "vd, vs2, vm" format, and I have added a few new instructions that do not have default test case values. So the source register data is completely random

[ksco]

Interesting, but I guess we can add some locks to resolve this.

[nadime15]

I am not very familiar with Go, but I do not think locking the goroutines is enough, since they can still start in an unpredictable order (?) which is the root cause.

What might work is giving each instruction its own independent random number generator (switching from rand to rand_r() or other alternatives), or else switching entirely to sequential execution and dropping goroutines. That would probably hurt performance, though maybe we could offer parallel execution as an optional feature.

[ksco]

I’ll come up with something tomorrow!

[nadime15]

Hi @ksco is your commit b39a70e related to this issue?

[ksco]

Yes, but it's still not enough for Testfloat cases to be stable.