Closed arturmelanchyk closed 5 months ago
Ok, as it turns out, Size()
is never used and EntriesCount()
is only used in TBtree::nodeAt()
which itself obtains exclusive lock, so there is no much sense in RWMutex here, unfortunately. Reverted the commit.
I don't have full context where this particular cache is used but in general this is a common and good approach to use RW locks for caches. When you mention using RW lock makes sens only if there is a good read vs write ratio this means you have to think twice if you really need cache.
I'm not generalizing because there are a couple use cases where having more writes than reads make sense but in most cases if there are more writes than reads then cache doesn't bring much value.
If you really really need high possible parallelism for writes then I guess the only reasonable ways are having many locks per hash pools or best way to implement lock-free list with CAS. Not sure if there are existing and maintained lock-free list implementations in Go.