txn-rw-register workload does not detect g0 write cycles under read-uncommitted consistency about maelstrom HOT 5 OPEN

Right, so I think this is a shortcoming in Elle's rw-register checker, which does pretty much all its inference through external reads and writes--IIRC, my rationale was that internal anomalies would be glaringly obvious, and it offers a pretty major speedup--a lot of problems gain an extra level of iteration if you consider internal reads/writes. I took a stab at changing that, and after seven hours I have to admit--this is a bigger problem than I was hoping. Elle is... fantastically complex, and has a lot of moving parts. Gotta shelve this for now.

from maelstrom.

Thank you @aphyr for your quick response and for all the work you have put into the Elle! This is an incredible project. And thank you for the Maelstrom. I had lots of pleasure playing with it. I will leave this thing open for future interesants. If you want just close it.

from maelstrom.

I don't know yet what a g0 write cycle is but my read ("r") responses can be completely arbitrary and still pass the same workload. To verify the boilerplate I had sat up, I simply put returned the same txn payload from request in the reply. No logic at all and to my surprise "Everything looks good!". Even a random integer as read value will do.

Is that the same issue as @sitano reported?

from maelstrom.

Naw, that's more like a garbage read, which is also something the rw-register workload should detect, but doesn't, because I am lazy and my entire life has been consumed with moving and house repairs for the last six months :(

from maelstrom.

I have now also reproduced the same with read-committed consistency. Random integers or null as read value passes for example:

maelstrom test -w txn-rw-register --bin ~/go/bin/maelstrom-txn --node-count 2 --concurrency 2n --time-limit 20 --rate 1000 --consistency-models read-committed --availability total –-nemesis partition

from maelstrom.