[concurrency-interest] On park and unpark
anmiller at redhat.com
Tue Sep 5 13:45:25 EDT 2017
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.
On Fri, Aug 25, 2017 at 10:49 AM, Nathan and Ila Reynolds <
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
> I recommend running some microbenchmark tests for the non-blocking case
> (i.e. unpark() before park()). You might see a CPU performance gain.
> 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.
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
Andrig (Andy) T. Miller
Global Platform Director, Middleware
Red Hat, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest