WiredTiger has an implementation of hazard pointers, that is used to give application threads a light weight mechanism to flag a page as in-use. The hazard pointer algorithm allows for readers (shared access) to be cheap at the cost of more expensive writers (exclusive access).

mathias@mongodb.com observed:

Doesn't the code to clear a hazard ptr need a release fence prior to storing the null? Otherwise I think reads and writes to that page's memory could be reordered after we have released our protection. While unlikely, I think that means that there is a possibility for some memory protected by that hazard pointer to have been freed then reused prior to some write that was supposed to be protected by the hazard pointer, and we end up writing to the new allocation which we weren't supposed to see yet. This seems equivalent to why the decrement on reference counts are always done with release. Is there some other fencing performed by all callers that prevents this, or have we just gotten lucky because the delay between clearing the hazard pointer and it being reused tends to be longer than the reorder window for CPUs?

Use this ticket to explore whether the correctness concern is valid and the code should be changed (or a comment extended to provide greater clarity).