[concurrency-interest] Measuring and expressing contention
aaron.grunthal at infinite-source.de
Sun Jul 20 22:15:10 EDT 2014
Have you tried the java.util.concurrent.atomic.LongAdder? It's designed
for statistics-keeping in situations where CAS on a single shared
cache-line causes too much contention.
And you should make sure your benchmarking is realistic, the CAS may be
expensive when it dominates your benchmark but could become
significantly less contended when some actual work is performed between
checking out objects from the pool and returning them.
On 20.07.2014 12:48, Chris Vest wrote:
> Hi fellas,
> I’m building an object pool (for fun, mostly) that one configures with
> an upper bound of how many objects it may contain, which means it can
> become a source of contention when the demand for the pooled objects is
> greater than the supply. In my implementation, this will effectively
> boil down to threads waiting on BlockingQueue.poll(timeout, unit) calls.
> I’m trying to come up with a good way to express the “current level of
> contention” to the outside world, whatever that means. Basically, I want
> to be able to tell an ops person that maybe the pool size has been
> configured too small, but I’m coming up short with ideas of how to do
> that without significant overhead. As for overhead, adding a CAS in the
> fast-path would reduce the throughput by about 30%, which is too much,
> but a CAS in the slowest-path case where the thread is going to block
> anyway would be perfectly fine.
> So, do you have any experience with solving something like this, or
> ideas for how to approach it?
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
More information about the Concurrency-interest