[concurrency-interest] On park and unpark

David Holmes davidcholmes at aapt.net.au
Tue Sep 5 16:56:39 EDT 2017


Hi Andy,

 

Can you elaborate further on this issue?

 

But given futex is also the underpinning of the pthread mutex/condvar, wouldn’t you see the same slow down in either case? Or is there something specific about calling futex API directly from the JVM.

 

Thanks,

David

 

From: Concurrency-interest [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of Andrig Miller
Sent: Wednesday, September 6, 2017 3:45 AM
To: Nathan and Ila Reynolds <nathanila at gmail.com>
Cc: Concurrency-interest <concurrency-interest at cs.oswego.edu>
Subject: Re: [concurrency-interest] On park and unpark

 

I know of a futex performance issue that remains in the kernel.  Whenever futex is called when the JVM is running in a virtual machine it performs very poorly.  In the particular case that made me aware of this issue, the slowdown was 50%.

 

To my knowledge, the kernel engineers have never been able to come up with a way to fix this issue.

 

Andy

 

On Fri, Aug 25, 2017 at 10:49 AM, Nathan and Ila Reynolds <nathanila at gmail.com <mailto:nathanila at gmail.com> > wrote:

Several years ago, I saw Linux futex perform poorly in the kernel.  Futex was getting a bad rap by others as well.  In my experience, the kernel would spend a lot of CPU time dealing with futexes.  I do not remember the circumstances that cause this scenario.  So, I recommend proceeding with caution and lots of testing.  Perhaps, this caution is not warranted and the problem was fixed in the kernel.

For the blocking case, I would guess there would not be much difference in performance.

I recommend running some microbenchmark tests for the non-blocking case (i.e. unpark() before park()).  You might see a CPU performance gain.

-Nathan



On 8/25/2017 10:28 AM, Doug Lea wrote:

On 08/25/2017 11:12 AM, Andrew Haley wrote:

On 25/08/17 12:12, Doug Lea wrote:

BTW, on linux, it should be more efficient to implement using
Futex instead of the current scheme based on original Solaris
version. But no one has ever volunteered to do this.

I've done it, and could not measure any difference.

Well, it should still save a few electrons (or millions, across
deployments), so still seems to be the Right Thing to do.

-Doug
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu <mailto:Concurrency-interest at cs.oswego.edu> 
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

 

-- 
-Nathan



_______________________________________________
Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu <mailto:Concurrency-interest at cs.oswego.edu> 
http://cs.oswego.edu/mailman/listinfo/concurrency-interest





 

-- 

Andrig (Andy) T. Miller

Global Platform Director, Middleware

Red Hat, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20170906/e4018919/attachment.html>


More information about the Concurrency-interest mailing list