[concurrency-interest] Measuring and expressing contention

Jeff Hain jeffhain at rocketmail.com
Mon Jul 21 18:31:57 EDT 2014

Hi Chris.

>So, do you have any experience with solving something like this, or ideas for how to approach it?

For the pure "contention" part (not starvation or measurement),
if you are ok with some spare instances that would not be counted
in your shared pool, what you can do is have thread-local buffers
of instances as proxies (threads would only see the pool through them),
and give them a max size of 100 or 1000 for example.

When a proxy gets empty, you half-fill it (in one shot of synchronization or alike),
and when it gets full you half-empty it ("half-" to reduce risk of flip-flop between full
and empty).

It can greatly reduce contention on the shared pool, and helps with thread
locality (when you put an instance in thread-local proxy, and then retrieves
the same instance from it).

If you use smart policies like timing etc. in your pools, make sure your pooling
still helps - I found it hard enough to beat GC throughput with pooling
even without this overhead.


PS : In my experience the most vicious bugs come from either threading or pooling,
so having a way to easily deactivate all your pools (i.e. use pools that actually don't pool)
can help a lot.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20140721/748d9304/attachment.html>

More information about the Concurrency-interest mailing list