perf: apply rw mutex to cachekv

[wetcod]

Description

When checkTx is executed concurrently, lock contention occurs on Read in cachekv.Store.
So modify cachekv.Store to use RWLock.
Also, since set cache in Read, concurrent-safe cache is required. So I use sync.Map.

-->

closes: https://github.com/line/lbm/issues/1187

---

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

• Targeted PR against correct branch (see CONTRIBUTING.md)
• Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
• Code follows the module structure standards.
• Wrote unit and integration tests
• Updated relevant documentation (docs/) or specification (x/<module>/spec/)
• Added relevant godoc comments.
• Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
• Re-reviewed Files changed in the Github PR explorer
• Review Codecov Report in the comment section below once CI passes

[codecov]

Codecov Report

Merging #204 (824f748) into v2/develop (4bf9d52) will increase coverage by 0.01%.
The diff coverage is 100.00%.

@@              Coverage Diff               @@
##           v2/develop     #204      +/-   ##
==============================================
+ Coverage       53.48%   53.49%   +0.01%     
==============================================
  Files             652      652              
  Lines           47341    47344       +3     
==============================================
+ Hits            25318    25325       +7     
+ Misses          19170    19166       -4     
  Partials         2853     2853              

Impacted Files	Coverage Δ
store/cachekv/store.go	91.34% <100.00%> (+4.21%)	⬆️

[egonspace]

Looks good!

[iproudhon]

I don't think sync.Map is necessary as it's accessed with lock held.

[wetcod]

I don't think sync.Map is necessary as it's accessed with lock held.

@iproudhon I think sync.Map is needed because concurrent set occurs in https://github.com/line/lbm-sdk/pull/204/files#diff-9d8fdb334ee27219ad1f8351ab43222e3450cbf889f2599f97bf6957743aa69fR67

[whylee259]

I think we should separate the read-only cache from the Store.cache.
If the unmodified values are staged to Store.cache through Get(), seems performance will be degraded because unnecessary writes are performed during Write().

[whylee259]

I think we should separate the read-only cache from the Store.cache.
If the unmodified values are staged to Store.cache through Get(), seems performance will be degraded because unnecessary writes are performed during Write().

Ah, it checks whether the item is dirty.
https://github.com/line/lbm-sdk/blob/dfef88dea841e983218f2f6f8875244e8d6b0c57/store/cachekv/store.go#L103

[wetcod]

Ah, it checks whether the item is dirty.

Yes, I think Store already writes only dirty elements in Write()

[iproudhon]

As it has over 66% update, sync.Map is the right choice. With that, I don't think we need RWLock. Instead, we can just use Mutex to protect setCacheValue, Write and iterator. Get() doesn't need lock protection.

[wetcod]

As it has over 66% update, sync.Map is the right choice. With that, I don't think we need RWLock. Instead, we can just use Mutex to protect setCacheValue, Write and iterator. Get() doesn't need lock protection.

@iproudhon When Rlock is removed, Get and Write are executed at the same time.
Then parent.Get and parent.Set can be called at the same time.
Since CacheKV is the only KVStore that has concurrency protection with lock, then it may cause problems.

[iproudhon]

Ok, I got it.