LRUCache optimizations

[arturmelanchyk]

• validate input params before obtaining mutex lock
• replace sync.Mutex with sync.RWMutex

[arturmelanchyk]

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.

[prog8]

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.

[coveralls]

coverage: 89.503% (-0.02%) from 89.519% when pulling 2c44fa20513a9150f8c6c32e77a098d6a7c550fb on arturmelanchyk:lru-cache-optimizations into 65a25a5b71de2522d93ea0c5f5fc585c9a7a9f69 on codenotary:master.