[wip] improve bug finding with Thread

[n-osborne]

No description provided.

[jmid]

I've now tried to clean-up my efforts on increasing the chance to trigger Thread issues.

• It contains a replacement Stdlib named Evilstdlib which shadows selected functions, such as (:=) with extended versions containing Thread.yield "to give scheduling hints, telling the scheduler that now is a good time to switch to other threads" in the words of the Thread documentation.
• To run Thread tests one then needs suitable dune curses to link against Evilstdlib and shadow the usual Stdlib

The stat benchmark with counts at 10000 is still running on my machine.
An earlier run with lower counts gave the following:

Stats:

Buggy ref int64 programs with Domain + Lin_api       737 / 1000
Buggy ref int64 programs with Domain + plain Lin     763 / 1000

Buggy ref int programs with Thread + Lin_api         478 / 1000
Buggy ref int64 programs with Thread + Lin_api       486 / 1000
Buggy CList int programs with Thread + Lin_api        39 /  250
Buggy CList int64 programs with Thread + Lin_api      38 /  250

Buggy ref int programs with Thread + plain Lin       376 / 1000
Buggy ref int64 programs with Thread + plain Lin     522 / 1000
Buggy CList int programs with Thread + plain Lin      25 /  250
Buggy CList int64 programs with Thread + plain Lin    23 /  250

These at least indicate reasonable chances to trigger issues.
I'll share the stat numbers for count 10000 once it completes.

I can see the branch has several conflicts.
We should rebase on a recent main and remove the code for the symbolic Yield-idea which turned out not to work 🤷
If we decide to go with this, Evilstdlib should probably also be moved to lib.

[jmid]

As promised here comes the stats:

$ dune exec src/neg_tests/stats.exe -- -v
random seed: 191305239
generated error  fail  pass / total     time test name
[✓] 10000     0     0 10000 / 10000   219.7s Buggy ref int64 programs with Domain + Lin_api
[✓] 10000     0     0 10000 / 10000   164.2s Buggy ref int64 programs with Domain + plain Lin
[✓] 10000     0     0 10000 / 10000   342.6s Buggy ref int programs with Thread + Lin_api
[✓] 10000     0     0 10000 / 10000   380.6s Buggy ref int64 programs with Thread + Lin_api
[✓] 10000     0     0 10000 / 10000  1973.7s Buggy CList int programs with Thread + Lin_api
[✓] 10000     0     0 10000 / 10000  2818.1s Buggy CList int64 programs with Thread + Lin_api
[✓] 10000     0     0 10000 / 10000   202.2s Buggy ref int programs with Thread + plain Lin
[✓] 10000     0     0 10000 / 10000   285.6s Buggy ref int64 programs with Thread + plain Lin
[✓] 10000     0     0 10000 / 10000  1510.2s Buggy CList int programs with Thread + plain Lin
[✓] 10000     0     0 10000 / 10000  1955.2s Buggy CList int64 programs with Thread + plain Lin
================================================================================
success (ran 10 tests)

Stats:

Buggy ref int64 programs with Domain + Lin_api     7309 / 10000
Buggy ref int64 programs with Domain + plain Lin   7428 / 10000

Buggy ref int programs with Thread + Lin_api       4589 / 10000
Buggy ref int64 programs with Thread + Lin_api     4723 / 10000
Buggy CList int programs with Thread + Lin_api     1616 / 10000
Buggy CList int64 programs with Thread + Lin_api   1611 / 10000

Buggy ref int programs with Thread + plain Lin     3513 / 10000
Buggy ref int64 programs with Thread + plain Lin   4992 / 10000
Buggy CList int programs with Thread + plain Lin   1041 / 10000
Buggy CList int64 programs with Thread + plain Lin 1080 / 10000

From the looks of it, this approach actually makes Lin_api trigger more issues in 3/4 cases...

[n-osborne]

Stalling branch, closing.