nickva commented on issue #4650: URL: https://github.com/apache/couchdb/issues/4650#issuecomment-1599240199
> So one thing to watch out for is that switching to a bucketing based histogram that is explicitly accurate in incrementing a bucket for every histogram update, we will drastically increase the amount of lock contention happening. That's why I thought counters might work here. With [write_concurrency] it does auto-stripping across schedulers https://www.erlang.org/doc/man/counters.html#new-2 > This is an optimization to achieve very efficient concurrent [add](https://www.erlang.org/doc/man/counters.html#add-3) and [sub](https://www.erlang.org/doc/man/counters.html#sub-3) operations at the expense of potential read inconsistency and memory consumption per counters. Read operations may see sequentially inconsistent results with regard to concurrent write operations. Even if write operation A is done sequentially before write operation B, a concurrent reader may see any combination of A and B, including only B. A read operation is only guaranteed to see all writes done sequentially before the read. No writes are ever lost, but will eventually all be seen. > The typical use case for write_concurrency is when concurrent calls to [add](https://www.erlang.org/doc/man/counters.html#add-3) and [sub](https://www.erlang.org/doc/man/counters.html#sub-3) toward the same counters are very frequent, while calls to [get ](https://www.erlang.org/doc/man/counters.html#get-2)and [put](https://www.erlang.org/doc/man/counters.html#put-3) are much less frequent. The lack of absolute read consistency must also be acceptable -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
