Read/write value cache locking would improve value cache concurrent access by history syncers. Currently history syncer locks value cache for every item in trigger expression. While the locks are not long, there are a lot of them. Directly replacing it with read locks is not possible, because of possible history caching and range/statistics updates. Still it could be done with some changes to the processing logic. As the cache is unlocked during database access it would be possible with minor refactoring to first read lock, then if cache update is required, unlock, access database, write lock, update cache. The range/statistics updates could be cached locally and then flushed to cache after the history batch is processed.

In theory that should improve the value cache concurrency, in practice it's not clear how much improvement it would give.