Skip to content

Releases: mgnsk/evcache

v2.3.2

12 Apr 10:10
a1f2df4
Compare
Choose a tag to compare
  • Fixes a race bug introduced by previous release where the transaction waitgroup might have panicked when loading a record which was just evicted.

Previous release had the false assumption that readers use a cache RLock but there is no such thing - the mutex is of type sync.Mutex.
Readers only use record locks, hence the need to interleave cache and record locks (safe only on active records) to prevent concurrent delete and perform the second state transition safely.

v2.3.1

08 Apr 14:24
0f9df62
Compare
Choose a tag to compare
  • Refactors most of the internals
  • Removes record locking when evicting. It relies of the fact that the check-lock-check (record mutex) pattern for readers only works on the state transition default -> active and the cache mutex handles the transition active -> evicting.
  • Documentation updates

v.2.3.0

04 Apr 18:30
0e3977b
Compare
Choose a tag to compare
  • Blocking mode now always blocks Fetch and Set even if no eviction callback set
  • Eviction process is simplified
  • Fixed busy spinning loop bug in blocking mode

v2.2.2

03 Apr 21:14
e1094fb
Compare
Choose a tag to compare
  • Fixes an invalid test where Evict is non-blocking anyway, the test tests that Fetch for new value in ModeNonBlocking doesn't block when an EvictionCallback for old key is running.

v2.2.1

03 Apr 21:01
fd961f3
Compare
Choose a tag to compare
  • Fixes a race condition in blocking mode where under a record lock, waitgroup needed to be incremented before updating the record state. This is necessary due to readers being asynchronous and deciding whether to Wait on the waitgroup based on record state.

v2.2.0

03 Apr 19:03
aa4ff55
Compare
Choose a tag to compare

This release introduces eviction modes.

  • There are two kinds of modes and the apply only when using an EvictionCallback. See the readme for the repo.
  • A long time race condition is fixed. An evicted record must not be reused in the pool. It is not know when the record stops being used since readers are not synchronized. A reader may load a value, meanwhile it may be evicted, the record reused in sync.Pool for another key and the first reader loads the wrong value. The pool still works for Fetch only and only if it does not store the record into the map.

v2.1.4

27 Mar 11:08
4674236
Compare
Choose a tag to compare
  • Removes invalid go.mod retract directive

v2.1.3

11 Mar 19:57
09a9318
Compare
Choose a tag to compare
  • Simplify code, fix invalid comment

v2.1.2

07 Mar 16:43
2b2253a
Compare
Choose a tag to compare
  • Testing and documentation updates

v2.1.1

27 Feb 14:55
1b7ef2a
Compare
Choose a tag to compare
  • Clean up code
  • Retract old versions with race conditions