TriggerMail / lazylru / 173

86%

master: 98%

push

buildkite

Fixing data race (#29)

When reading and writing the same key simultaneously, there were two races that could occur while escalating the lock from a reader lock to a writer lock in the `get` method.

* The expiration check in `get` was reading `pqi.expiration`
* The returned value in `get` was reading `pqi.value`

Both of happened after the call to `lru.lock.RUnlock()`, which means that set could have modified the item that `pqi` was pointing to. We are now copying the underlying item (`*pqi`) to the stack and referencing that. This is a pessimistic way to approach this problem, but it is safe.

A test was added that highlighted these races when run with `-race`.

Thanks @coxley for pointing these out and giving me a test that showed the problem.

11 of 11 new or added lines in 1 file covered. (100.0%)

1404 of 1642 relevant lines covered (85.51%)

1829345.46 hits per line