Reading about it, the FoundationDB testing does look very good. If you control all of the atomic events and build a fuzzer on top, you can indeed end up with reproducible scenarios testing concurrency, up to the atoms' scope.
In the async scenarios as with Tokio and Flow(which I just learned about, cheers), the atomicity extends to the scheduler yields, which is already pretty good. It cannot test e.g. atomic memory operations/memfences etc but it can test in a fairly fine-grained way.
However, my original point still stands: you can only do this if you control all of the system within your particular scheduler. In real world scenarios you are more likely to encounter:
1. Some database written in C
2. Some storage layer maintained by AWS/Azure/GCP
3. Some messaging layer written in Go
4. Failover modes of the Kubernetes/Hashicorp stack
5. Your node.js webserver named "backend"
6. Some performance-sensitive component written in Rust
In the async scenarios as with Tokio and Flow(which I just learned about, cheers), the atomicity extends to the scheduler yields, which is already pretty good. It cannot test e.g. atomic memory operations/memfences etc but it can test in a fairly fine-grained way.
However, my original point still stands: you can only do this if you control all of the system within your particular scheduler. In real world scenarios you are more likely to encounter:
1. Some database written in C
2. Some storage layer maintained by AWS/Azure/GCP
3. Some messaging layer written in Go
4. Failover modes of the Kubernetes/Hashicorp stack
5. Your node.js webserver named "backend"
6. Some performance-sensitive component written in Rust
This sort of testing just does not apply