[concurrency-interest] strange performance issue with ArrayBlockingQueue on Linux
Brian S O'Neill
bronee at gmail.com
Thu Jul 20 12:45:17 EDT 2017
In this particular test, the number of active threads was less than or
equal to the number of logical cores. So any cost due to unpark possibly
triggering a yield shouldn't apply. My understanding is that park/unpark
on Linux relies on a futex, and so perhaps this is just one kernel call.
On 2017-07-20 07:45 AM, Nathan and Ila Reynolds wrote:
> > I've never understood why unpark always comes up as a performance
> bottleneck. What does it do that's so expensive?
> A while ago, I talked with the engineer who has done a lot of
> optimization on LockSupport.unpark(). I can't remember if that implies
> On Windows, LockSupport.unpark() goes into the kernel 1 time to set a
> Windows Event object. On Linux, LockSupport.unpark() acquires a lock,
> sets a condition wait and releases a lock. This *might* require 3 trips
> into the kernel.
> Furthermore, the scheduler might let the unparked thread start running
> and unparking thread yield (if no logical cores are available). Hence,
> unpark() will take even more time.
More information about the Concurrency-interest