[concurrency-interest] Abstract Stacked Synchronizer?
viktor.klang at gmail.com
Mon Mar 30 03:34:23 EDT 2020
TBH it would be interesting to have the size driven by utilization—it looks
to be rather straightforward to use Queuing Theory in this case and have
each worker keep track of time-spent-servicing vs time-spent-waiting.
On Sun, Mar 29, 2020 at 11:40 PM Carl M via Concurrency-interest <
concurrency-interest at cs.oswego.edu> wrote:
> I have a ThreadPoolExecutor that showed some surprising behavior. It is
> configured to have a core pool size of 10, max size of 400, and a keep
> alive time of 1 minute. When the code runs, short lived tasks are executed
> on the executor at a high rate, about 300 per second. These tasks only
> take about 10ms each, so there isn't much work to do.
> What I noticed is that spikes in load cause the pool size to go up, but it
> never goes back down. This makes sense, but it isn't a desired behavior.
> When the rate of tasks submitted goes beyond the queue size, more threads
> are brought in, take the work, and then contend on the queue. The queue
> uses a AbstractQueuedSynchronizer, which enqueues threads to accept more
> The problem here is that thread are effectively round-robin as work comes
> in (even in unfair mode). Each time a 10ms task comes in, it's enough
> time for the other threads to move up in line. In effect, despite there
> being hardly enough work to for hundreds of threads, because the load is
> spread so evenly among them, they never reach the keep alive timeout.
> What I think the solution to this should be is a BlockingQueue that has an
> unfair Lock. The least-fair lock that can be made, where threads always
> cut in line to be at the front. I believe using a stack instead of a queue
> in AQS would lower the thread pool size much more aggressively.
> Considering how little work is actually coming in, I don't think
> contention between the threads would be a serious issue.
> Does something like this exist?
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest