Re: Low-latency pause in JDK

> For example, I have later removed
nearly every occurrence of Thread.yield() in any code I've written after
finding something better or more general

OT: Just curious, where? :)

Il sab 26 ott 2019, 20:08 Doug Lea via Concurrency-interest <
[email protected]> ha scritto:

> On 10/26/19 7:37 AM, Viktor Klang via Concurrency-interest wrote:
> > Given that the strategy will depend on the runtime environment, a JDK
> > "intrinsic" would make most sense to me—hence wanting something in the
> > JDK :)
>
> Considering that a general solution would provide the best course of
> action whenever entities (for example you, or some thread) momentarily
> cannot get something they momentarily want (a lock, a new JDK method),
> this is a hard request to fulfill! The best we've been able to do is
> make internal choices (in locks, queues, etc) that are OK with respect
> to more concrete contexts. In addition to issues that other people have
> mentioned, solutions also interact with choice of garbage collector.
>
> I agree that it might be would be nice to expose some of the lower-level
> features available on some platforms that might sometimes provide better
> performance, but these also tend to be hard to encapsulate in APIs in
> ways that do more good than harm. (For example, I have later removed
> nearly every occurrence of Thread.yield() in any code I've written after
> finding something better or more general.)
>
> And as always (especially in real life), whenever you encounter a
> problem involving blocking, the main question to ask is whether there is
> something you can do other than block -- helping, choosing alternate
> actions, speculating, etc.
>
> -Doug
>
>
> >
> > On Sat, Oct 26, 2019 at 10:23 AM Francesco Nigro <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> >     I mean RDTSC, missed the final C :P
> >
> >     Il sab 26 ott 2019, 12:07 Francesco Nigro <[email protected]
> >     <mailto:[email protected]>> ha scritto:
> >
> >         I was hoping that for parking times <  granularity offered by
> >         the OS would make sense a mm_pause (possibility not broken) spin
> >         loop while using rdts to measure the elapsed time (+ lfence, if
> >         needed, but maybe with the pause isn't necessary). And no
> >         safepoint polls in the spin wait loop.
> >         I know that on oversubscribed systems (more active threads then
> >         core) isn't a great solution but would be nice to have some way
> >         to perform a low latency sleep.
> >         Implementing by myself saving the safepoint poll to be injected
> >         in an uncounted loop is not that trivial...
> >
> >         Il sab 26 ott 2019, 11:23 Andrew Haley via Concurrency-interest
> >         <[email protected]
> >         <mailto:[email protected]>> ha scritto:
> >
> >             On 10/25/19 11:11 AM, Viktor Klang via Concurrency-interest
> >             wrote:
> >             >
> >             > Is there any jdk-builtin Java8+ method which tries to be
> >             clever
> >             > about low-nanos/micros parking?
> >             >
> >             > I'm currently considering LockSupport.parkNanos but want
> >             to avoid
> >             > having the Thread parked when parking + wake-up latency is
> >             more
> >             > likely to be much greater than the requested time.
> >             >
> >             > I.e. some combination of onSpinWait + some
> non-cache-polluting
> >             > computation + yielding + actual parking. I'd like to avoid
> >             having to
> >             > custom-roll it, hence the question for prior art ;)
> >
> >             As I understand it, the common wisdom is to wait for about
> >             half the
> >             round-trip time for a system call and then park. It doesn't
> >             sound
> >             terribly hard to write something to do that.
> >
> >             Please forgive me for digressing, but:
> >
> >             Arm has a mechanism to do this, WFE. When a core fails to
> >             obtain a
> >             lock it executes a WFE instruction which waits on the cache
> line
> >             containing the lock. When that cache line is written to by
> >             the core
> >             releasing the lock it awakens the waiting core.
> >
> >             I'd like to find some way to expose this in a high-level
> >             language but
> >             it's not at all easy to do.
> >
> >             I believe that Intel has MWAIT which is similar, but it's a
> >             privileged
> >             instruction so no use to us.
> >
> >             --
> >             Andrew Haley  (he/him)
> >             Java Platform Lead Engineer
> >             Red Hat UK Ltd. <https://www.redhat.com>
> >             https://keybase.io/andrewhaley
> >             EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> >
> >             _______________________________________________
> >             Concurrency-interest mailing list
> >             [email protected]
> >             <mailto:[email protected]>
> >             http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> >
> >
> >
> > --
> > Cheers,
> > √
> >
> > _______________________________________________
> > Concurrency-interest mailing list
> > [email protected]
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> >
>
>
> _______________________________________________
> Concurrency-interest mailing list
> [email protected]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>

_______________________________________________
Concurrency-interest mailing list
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest