Store sequential lock implementation can cause failure
Closed this issue · 1 comments
The store utilizes a seqlock to protect reads from corruption during writes. Concurrent writes are precluded by the use of an ordered strand.
The seqlock pattern allows in-progress reads to continue during writes, while blocking new reads until the write completes. This prevents writer starvation in scenarios where writes are fast and limited in quantity relative to reads. Any read that spans a write is invalidated and reattempted once the write is complete.
The presumption is that, while the read-while-write may produce invalid results, it will not cause a catastrophic failure. In a previous implementation a catastrophic failure did result from the ordering of pointer updates, where the reader ended up in an infinite loop. This was resolved, but other issues remain.
The writer places pointer values using a byte-based serialization. This is non-atomic - any part of a pointer update may be read by the reader during the writer update. In other words, the first 1-7 bytes of the pointer may be updated in the pointer read by the reader. This would lead to an invalid offset, resulting in a corrupt read and/or (ideally) segmentation fault.
A restart would clear the error until a subsequent occurrence, unless corrupted read data was used in a subsequent write. Reads invoked by the writer are not affected, as the writer maintains consistency within its operations.
This issue has been moved to the libbitcoin-database repo.