Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Backport rescale bug #1046
In both the original and updated implementations, while a thread is performing the rescale operation (within the write lock) all concurrent updates block until the rescale operation is complete. There are behavioral differences there, however nothing fundamental changes with respect to the impact on other concurrent updates while the rescale operation is ongoing - could you clarify your concern there?
Note that the race condition the patch fixes allowed updates to sometimes be added to the reservoir outside of the rescale window (that is, without a preceding rescale operation). The fix merely enforces that requirement; updates outside of the rescale window are forced to wait for the rescale operation to complete before updating the reservoir's state. There are other implementations that would accomplish that - the write lock barrier is more than is strictly required there:
One approach would be to add a second atomic to
Alternatively, rather than enforcing the above requirement, it could be relaxed and the reservoir could be refactored accordingly. For example, a cache could be added to the reservoir to collect updates added in
Note, however, both of the above would add significant complexity to the reservoir. I'm not certain it's at all worthwhile given that the window during which multiple concurrent calls to