[concurrency-interest] Measuring and expressing contention

Chris Vest mr.chrisvest at gmail.com
Sun Jul 20 06:48:09 EDT 2014

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?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20140720/a7589084/attachment.html>

More information about the Concurrency-interest mailing list