Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

🩹 Fix: race condition in memory storage #2669

Closed
wants to merge 1 commit into from
Closed

🩹 Fix: race condition in memory storage #2669

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 5 additions & 5 deletions internal/storage/memory/memory.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -137,9 +137,9 @@ func (s *Storage) gc() {
}
}

// Return database client
func (s *Storage) Conn() map[string]entry {
s.mux.RLock()
defer s.mux.RUnlock()
return s.db
// ConnLocked can be used to access the underlying db in a thread-safe manner.
func (s *Storage) ConnLocked(f func(map[string]entry)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an interface, we shouldn't rename it to avoid breaking changes.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gaby What interface does this implement?

I can see the earlier Conn method only on this struct
https://sourcegraph.com/search?q=context:global+repo:https://github.com/gofiber/fiber/+%22Conn()%22&patternType=standard&sm=1&groupBy=repo

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://github.com/gofiber/storage/blob/main/storage.go

We may need to discuss this, since it's implemented differently in multiple places 🤔

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I understand, this method is only provided by memory.Storage, because I don't think any other storage will return a Conn of type map[string]entry.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no this method is provided by all adapters
https://github.com/search?q=repo%3Agofiber%2Fstorage%20conn&type=code

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see

I think we can make Storage.db a sync.Map so we can return it as it is from Conn(), without worrying about thread safety.

Thoughts @gaby , @ReneWerner87 ?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A ping on this in case it was missed. @gaby @ReneWerner87

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sync.Map is ok, but slower or ?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can run the Benchmark_Storage_Memory and see if it's better or worse.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ReneWerner87 sync.Map based implementation is slower than existing implementation for Benchmark_Storage_Memory:

Existing Implementation Results:

Screenshot 2023-10-16 at 9 20 21 PM

sync.Map based implementation Results:

Screenshot 2023-10-16 at 9 20 36 PM

But our choice should not depend on the benchmark we have. From sync.Map Documentation:

The Map type is optimized for two common use cases: (1) when the entry for a given key is only ever written once but read many times, as in caches that only grow, or (2) when multiple goroutines read, write, and overwrite entries for disjoint sets of keys. In these two cases, use of a Map may significantly reduce lock contention compared to a Go map paired with a separate Mutex or RWMutex.

So if Storage's use case aligns with one of the above two points, we can go ahead and use sync.Map. Else we can have another interface layer on top of vanilla map with RWMutex which we can return from Conn()

s.mux.Lock()
defer s.mux.Unlock()
f(s.db)
}
34 changes: 32 additions & 2 deletions internal/storage/memory/memory_test.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -124,9 +124,39 @@ func Test_Storage_Memory_Close(t *testing.T) {
utils.AssertEqual(t, nil, testStore.Close())
}

func Test_Storage_Memory_Conn(t *testing.T) {
func Test_Storage_Memory_ConnLocked(t *testing.T) {
t.Parallel()
utils.AssertEqual(t, true, testStore.Conn() != nil)
assertConn := func(db map[string]entry) {
utils.AssertEqual(t, true, db != nil)
}
testStore.ConnLocked(assertConn)
}

func Test_Storage_Memory_ConnLocked_Race(t *testing.T) {
key := "test_race"
done := make(chan bool)
read := func(db map[string]entry) {
_ = db[key]
}
write := func(db map[string]entry) {
db[key] = entry{}
}
doUntilDone := func(fn func(map[string]entry)) {
for {
select {
case <-done:
return
default:
testStore.ConnLocked(fn)
}
}
}

go doUntilDone(read)
go doUntilDone(write)

time.Sleep(100 * time.Millisecond)
done <- true
}

// go test -v -run=^$ -bench=Benchmark_Storage_Memory -benchmem -count=4
Expand Down
Loading