Update the access time of a cached entry immediately after the entry is read #363
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #359.
(We will merge this into themain
branch after #348 is merged)Problem
When a cached entry is read (by e.g. the
get
method) or write (by e.g. theinsert
method), thelast_accessed
time of the entry is updated. Whentime_to_idle
of theCache
is set, thelast_accessed
time is used to determine whether the entry is expired or not.Up to Moka
v0.12.1
,last_accessed
time was eventual consistent for read operations. So it will not be updated immediately after read, but will be updated sometime later when pending tasks are processed. (Note: It will be updated to the time when read was performed, not to the time when pending task is processed). This was designed so to achieve better throughput as updatinglast_accessed
has a small performance overhead from a synchronous primitive such asAtomicU64
when the default features are enabled, andMutex
when theatomic64
orquanta
feature is disabled.Note that
last_accessed
time is strong consistent for write operations, and it is updated during the write.Before
v0.12.0
, pending tasks were processed periodically (every ~0.3 secs) by a background thread, so the delay after read was not obvious. However we removed the background thread completely fromv0.12.0
, and the delay becomes obvious.Fix
Like the write operations, make
last_accessed
strong consistent for read operations.