Skip to content

Commit

Permalink
update test and readme
Browse files Browse the repository at this point in the history
  • Loading branch information
Yiling-J committed Oct 18, 2024
1 parent 0c4c118 commit 568709d
Show file tree
Hide file tree
Showing 2 changed files with 6 additions and 3 deletions.
5 changes: 4 additions & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -58,7 +58,10 @@ For READ events, a race condition could occur under the following scenario:

In this case, the policy may incorrectly promote EntryB. However, the likelihood of this scenario is extremely low. One potential situation where this could happen is if, after EntryA is added to the buffer, all reads stop, and only writes remain. Since the read buffer is only sent to the policy when it is full, this race condition may occur. **If a race happens for READ events, the entry might be incorrectly promoted to the head of the policy's LRU.**

For UPDATE events, a similar race condition might occur, but it is less likely because the write buffer is a channel that drains proactively, not just when full. Additionally, when the policy processes UPDATE events, it checks the key again to ensure it matches. **If a race occurs for UPDATE events, the entry's cost stored in the policy might differ from the actual cost.**
For UPDATE events, a similar race condition might occur under heavy concurrent UPDATE and INSERT operations. Both update and insert actions are needed to trigger the race because inserts to the policy can cause evictions, leading to the reuse of entries by the pool. Unlike reads, the write buffer is a channel that drains proactively, not just when full. Additionally, when the policy processes UPDATE events, it checks the key again to ensure it matches. **If a race occurs for UPDATE events, the entry's cost stored in the policy might differ from the actual cost.**


A correctness test runs as part of the CI, simulating heavy concurrent UPDATE and INSERT operations with a Zipf-distributed workload. This test verifies that the entry's policy cost (weight) matches its actual cost (weight). You can find the test here: [cache_race_test.go](https://github.com/Yiling-J/theine-go/blob/main/cache_race_test.go).

This option was introduced in Theine v0.5.1. Before this version, the entry pool was always used. Starting from v0.5.1, the `UseEntryPool` option was added and defaults to **false**.

Expand Down
4 changes: 2 additions & 2 deletions cache_race_test.go
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,7 @@ import (
func keyGen() []uint64 {
keys := []uint64{}
r := rand.New(rand.NewSource(0))
z := rand.NewZipf(r, 1.01, 9.0, 200000)
z := rand.NewZipf(r, 1.01, 9.0, 20000000)
for i := 0; i < 2<<16; i++ {
keys = append(keys, z.Uint64())
}
Expand All @@ -38,7 +38,7 @@ func getSet(t *testing.T, entrypool bool) {
go func() {
defer wg.Done()
rd := rand.Intn(2 << 16)
for i := 0; i < 100000; i++ {
for i := 0; i < 500000; i++ {
keyGet := keys[(i+rd)&(2<<16-1)]
keyUpdate := keys[(i+3*rd)&(2<<16-1)]

Expand Down

0 comments on commit 568709d

Please sign in to comment.