Technically torn reads can succeed
Closed this issue · 2 comments
mtak- commented
This is a ridiculous corner case.
Thread 1:
Starts a read, getting a sequence number, and reads some of the data.
Other threads:
Successfully perform exactly 2^(mem::size_of::<usize>() - 1) writes, leaving the sequence number effectively unchanged.
Thread 1:
Finishes reading the data, and sees the sequence number unchanged. It then returns the torn read.
On 64-bit machines, this would take a few lifetimes to occur, on 32-bit machines it might require the reader thread to be inactive for around one second.
Amanieu commented
Yes, this is a known issue with seqlock. However the probability of hitting this is so low that it may as well be non-existent.
mtak- commented
That makes sense. Thanks for checking this out. I'll go ahead and close this issue.