pingora icon indicating copy to clipboard operation
pingora copied to clipboard

Optimize memory cache's singleflight performance

Open 2547409617 opened this issue 1 year ago • 1 comments

What is the problem your feature solves, or the need it fulfills?

Acquiring write locks is not that easy in a high-concurrency environment, imagine there are many read lock requests, the write lock will be acquired later. After write lock acquired perhaps another one has already completed the lookup and removed the lock from locker container.

Describe the solution you'd like

After write lock acquired, we should first check whether data already exists at the current point.

Describe alternatives you've considered

What other solutions, features, or workarounds have you considered that might also solve the issue? What are the tradeoffs for these alternatives compared to what you're proposing?

Additional context

This could include references to documentation or papers, prior art, screenshots, or benchmark results.

2547409617 avatar Mar 05 '24 05:03 2547409617

suppose there are two threads(coroutine) t1 t2 t1 get data -> None t1 get container read lock, get CacheLock -> None t1 get container write lock, insert CacheLock t1 lookup data t2 get data -> None t2 pause for some reason such as thread switching t1 put lookuped data t1 get container write lock, remove CacheLock t2 resume and get container read lock, get CacheLock -> None t2 get container write lock, insert another CacheLock t2 lookup data

So it is waste that t2 lookup data in this situation. Double check should be done when get write lock like thread-safe lazy initialization.

2547409617 avatar Mar 06 '24 05:03 2547409617