Serious concurrency problems on fast systems
in [Java Programming]
|
Prev: DOWNLOAD FREE PALTALK LIVE VIDEO AND VOICE CHAT SOFTWARE
Next: Should -Xmx be a multiple of -Xms?
From: Mike Amling on 2 Jun 2010 09:52 Arne Vajh�j wrote: > -XXdonotkickthreadoffcpuifitisabadtimeforperformance does not exist. No, but someday there could be an option to let a Thread synchronized on a monitor for which another Thread is waiting run a little longer, in hope that it will desynchronize. --Mike Amling
From: Patricia Shanahan on 2 Jun 2010 10:13 Mike Amling wrote: > Arne Vajh�j wrote: >> -XXdonotkickthreadoffcpuifitisabadtimeforperformance does not exist. > > No, but someday there could be an option to let a Thread synchronized > on a monitor for which another Thread is waiting run a little longer, in > hope that it will desynchronize. If the kernel developers wanted to do something to solve priority inversion, why not implement priority inheritance, a long studied technique? Increasing the effective priority of threads that hold synchronized resources without taking into account whether there are threads waiting, and the priority of the waiting threads, would merely lead to every thread on a shared system being synchronized on something all the time. Patricia
From: Patricia Shanahan on 2 Jun 2010 10:16 Kevin McMurtrie wrote: .... > To clarify a bit, this isn't hammering a shared resource. I'm talking > about 100 to 800 synchronizations on a shared object per second for a > duration of 10 to 1000 nanoseconds. Yes, nanoseconds. That shouldn't > cause a complete collapse of concurrency. > .... Have you considered other possibilities, such as memory thrashing? The resource does not seem heavily enough used for contention to be a big issue, but it is about the sort of access rate that is low enough to allow a page to be swapped out, but high enough for the time waiting for it to matter. Patricia
From: Eric Sosman on 2 Jun 2010 11:01 On 6/2/2010 10:13 AM, Patricia Shanahan wrote: > Mike Amling wrote: >> Arne Vajh�j wrote: >>> -XXdonotkickthreadoffcpuifitisabadtimeforperformance does not exist. >> >> No, but someday there could be an option to let a Thread synchronized >> on a monitor for which another Thread is waiting run a little longer, >> in hope that it will desynchronize. > > If the kernel developers wanted to do something to solve priority > inversion, why not implement priority inheritance, a long studied > technique? The "I've just acquired a lock; please don't slice me yet" hint is independent of priority inheritance. Both are useful, either alone or in combination. Solaris does both (or can, when asked politely). I don't happen to know whether the JVM on Solaris makes the appropriate prayers and sacrifices to get this to happen, but it certainly could. Other O/S'es may offer similar capabilities, and their JVM's may (or may not) use them. I think we're in agreement, though, that it's not the sort of thing that the Java coder should try to control directly by juggling priorities or something. Scheduling is a system-wide allocation of resources; the Java programmer's world view extends only to his own application -- and maybe not even that far, if he's writing classes that will be used in many applications. The Java programmer has insufficient information to make informed decisions about system- wide (and shifting) resource demands. -- Eric Sosman esosman(a)ieee-dot-org.invalid
From: ClassCastException on 2 Jun 2010 13:28
On Wed, 02 Jun 2010 11:01:06 -0400, Eric Sosman wrote: > On 6/2/2010 10:13 AM, Patricia Shanahan wrote: >> Mike Amling wrote: >>> Arne Vajhøj wrote: >>>> -XXdonotkickthreadoffcpuifitisabadtimeforperformance does not exist. >>> >>> No, but someday there could be an option to let a Thread synchronized >>> on a monitor for which another Thread is waiting run a little longer, >>> in hope that it will desynchronize. >> >> If the kernel developers wanted to do something to solve priority >> inversion, why not implement priority inheritance, a long studied >> technique? > > The "I've just acquired a lock; please don't slice me yet" hint > is independent of priority inheritance. Could this be a use for Thread.yield()? Yield just before acquiring a lock, maybe less likely to get a context switch during the critical section since the C.S. will be entered right at the start of your next slice? |