Also, setting max_threads_for_updates cannot be tuned both from SQL query and xml config because of https://github.com/ClickHouse/ClickHouse/blob/master/src/Dictionaries/DictionaryFactory.cpp#L37-L41.

If we remove these two unlockers https://github.com/ClickHouse/ClickHouse/blob/master/src/Dictionaries/CacheDictionary.cpp#L882-L892 than it should work as expected, but the whole idea of non-blocking read will be broken.

When I add more granular locks (both read for update and write for rest) my server hangs without any information from thread sanitizer :(

Traces from gdb when server hangs https://gist.github.com/alesapin/46a52d33d89f100c67cff3c4cff4bea8
https://gist.github.com/alesapin/df27abfa0db390a35cab43ecd66ee838

I don't understand why the server is not able to drop the view or underlying table. Nobody holds table's drop lock, new select queries also wait for table drop lock (because DROP already in lock's queue) or some locks inside CacheDictionary. The only idea is that the timed part of our fair RWLock has a bug. Two reasons:

1. When I remove all code about waitings everything works fine https://gist.github.com/alesapin/317b292cb323050febd43f79d392b67a.
2. Seems like a query from clickhouse dictionary is internal and has no query_id, and in RWLock.cpp we have suspiciously many lines about locks without query_id.

All tests passed, I have just renamed method.