[concurrency-interest] Measuring and expressing contention

Chris Vest mr.chrisvest at gmail.com
Tue Jul 22 03:08:32 EDT 2014


Hi Jeff,

I already use ThreadLocals to reduce contention, though it does something simpler than what you describe, and does not require threads to each grab their own client/proxy/facade:
https://github.com/chrisvest/stormpot/blob/6d45381bfc899f93eb912b0cec86bf425a62d57f/src/main/java/stormpot/BlazePool.java#L89

The pool is designed for relatively expensive-to-allocate objects, such as network connections, so I assume that normal allocation will always be slower in the use cases the pool is applied to.

Alex,

I know about HdrHistogram, but I think it ought to be possible to do something simpler than that, when the goal is answering the question “Is the pool big enough?"

Cheers,
Chris

On 22 Jul 2014, at 00:31, Jeff Hain <jeffhain at rocketmail.com> wrote:

> 
> 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.
> 
> 
> -Jeff
> 
> 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/20140722/fe7829f4/attachment.html>


More information about the Concurrency-interest mailing list