This post is more targeted to Light, Togo and the devs and not the general audience.
Although this is not an emergency at this time I think this article has an extremely important influence for our design scalability, although that also depends on if we eventually become stratis based or stay with berkeleydb.
The crux of the article deals with atomic locks vs standard mutexes - Bitcoin (and we) use mostly standard mutexes called critical sections. What surprised me the most is the performance level difference on windows vs linux. An atomic lock in their test scenario (which is 1 million iterations with a 1/49th write vs read level) was 200* faster than a mutex lock on linux and windows. What is horrifying though, is that non-atomic locks are 20,000 times slower on windows, and worse, critical sections are 100 times slower on windows than linux. Since we use critical section mutexes of course that is relatively horrifying. However, we dont lock that often, its more of when the user initiates a call for data (such as when they run an rpc command), then the main GUI overview thread for example is locked, while the wallet harvests data, the rpc fills the return buffers then the lock is relinquished. (Note this does not affect mining as that is done on a dedicated thread- this affects *waiting* and serialized operations, slowing the entire experience down in situations where blocking occurs). So the actual lock/unlock frequency is very low, hence it has not become a problem. But we should use this example to at least search and find all locks that are frequent and mark them in the code. If they are adding overhead, we should consider moving (those particular sections) to atomic locks.
See the Test Results section here in the middle of the page:
https://www.arangodb.com/2015/02/comparing-atomic-mutex-rwlocks/ 
