[concurrency-interest] strange performance issue with ArrayBlockingQueue on Linux

[Brian S O'Neill]

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 
> Unsafe.unpark().
> 
> 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.
> 
> -Nathan
>