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: Eric Sosman on 2 Jun 2010 15:07 On 6/2/2010 1:28 PM, ClassCastException wrote: > On Wed, 02 Jun 2010 11:01:06 -0400, Eric Sosman wrote: >> >> 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? You seem to be making a lot of assumptions about how the scheduler works. Even the existence of "time slices" is not a given (real-time schedulers, for example, quite often don't use them). If the scheduler does in fact use time slices, how do you know that a "no-op" yield() gets you a fresh slice instead of just a continuation of the old one? And so on, and so on ... -- Eric Sosman esosman(a)ieee-dot-org.invalid
From: ClassCastException on 2 Jun 2010 16:19 On Wed, 02 Jun 2010 15:07:52 -0400, Eric Sosman wrote: > On 6/2/2010 1:28 PM, ClassCastException wrote: >> On Wed, 02 Jun 2010 11:01:06 -0400, Eric Sosman wrote: >>> >>> 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? > > You seem to be making a lot of assumptions about how the > scheduler works. No; the only assumption being made is that the shorter the interval since a thread has resumed, the lower the probability of its being preempted in the next x nanoseconds for some fairly small value of x. I don't think that that's an unreasonable assumption; context switches are expensive enough that a reasonably-designed OS scheduler is probably going to avoid frequently putting two of them (on the same core) too close together in time.
From: Tom Anderson on 2 Jun 2010 16:28 On Wed, 2 Jun 2010, 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? I don't understand the details, but there are people who are not keen on it. I think because (a) it can be slow and (b) it can let developers get away with writing bad code, although the latter sounds like a bullshit reason to me. Anyway, Linux has priority-inheriting mutexes in the real-time edition, and as the infrastructure underlying futexes in recent normal versions. If java uses futexes on linux, then it already has priority inheritance. However, priority inheritance, UIVMM, makes no difference at all if the threads involved are all of the same priority. If a priority-N thread blocks on a lock held by a priority-N thread, there is no boost to apply, and nothing in priority inheritance that will get the first thread off the lock any quicker. Something that might help is directed yields: if a thread blocks on a lock with some time left in its timeslice, it donates it to the thread holding the lock (which then uses all of it, or runs until it releases the lock, or something). I've come across the idea in IPC mechanisms: process A runs an IPC primitive which sends a message to process B and waits for a reply; since A is blocked, it might as well give its time to B in the hope that B will reply sooner. It's a fairly straightforward extension to apply that to locking. tom -- Like Kurosawa i make mad films; okay, i don't make films, but if i did they'd have a samurai.
From: Eric Sosman on 2 Jun 2010 16:30 On 6/2/2010 4:19 PM, ClassCastException wrote: > On Wed, 02 Jun 2010 15:07:52 -0400, Eric Sosman wrote: > >> On 6/2/2010 1:28 PM, ClassCastException wrote: >>> On Wed, 02 Jun 2010 11:01:06 -0400, Eric Sosman wrote: >>>> >>>> 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? >> >> You seem to be making a lot of assumptions about how the >> scheduler works. > > No; the only assumption being made is that the shorter the interval since > a thread has resumed, the lower the probability of its being preempted in > the next x nanoseconds for some fairly small value of x. I don't think > that that's an unreasonable assumption; context switches are expensive > enough that a reasonably-designed OS scheduler is probably going to avoid > frequently putting two of them (on the same core) too close together in > time. Dear Sir or Madam (as the case may be), You may be right, at that. Sincerely, E.A.S. (With apologies to George Bernard Shaw.) -- Eric Sosman esosman(a)ieee-dot-org.invalid
From: Arne Vajhøj on 2 Jun 2010 19:59
On 02-06-2010 00:57, Mike Schilling wrote: > > > "Arne Vajh�j" <arne(a)vajhoej.dk> wrote in message > news:4c059872$0$272$14726298(a)news.sunsite.dk... >> On 01-06-2010 00:21, Kevin McMurtrie wrote: >>> I've been assisting in load testing some new high performance servers >>> running Tomcat 6 and Java 1.6.0_20. It appears that the JVM or Linux is >>> suspending threads for time-slicing in very unfortunate locations. >> >> That should not come as a surprise. >> >> The thread scheduler does not examine the code for convenience. >> >> Correct code must work no matter when the in and out of >> CPU happens. >> >> High performance code must work efficiently no matter when the >> in and out of CPU happens. >> >> > For >>> example, a thread might suspend in Hashtable.get(Object) after a call to >>> getProperty(String) on the system properties. It's a synchronized >>> global so a few hundred threads might pile up until the lock holder >>> resumes. Odds are that those hundreds of threads won't finish before >>> another one stops to time slice again. The performance hit has a ton of >>> hysteresis so the server doesn't recover until it has a lower load than >>> before the backlog started. >>> >>> The brute force fix is of course to eliminate calls to shared >>> synchronized objects. All of the easy stuff has been done. Some >>> operations aren't well suited to simple CAS. Bottlenecks that are part >>> of well established Java APIs are time consuming to fix/avoid. >> >> High performance code need to be designed not to synchronize >> extensively. >> >> If the code does and there is a performance problem, then fix >> the code. >> >> There are no miracles. > > Though giving a thread higher priority while it holds a shared lock > isn't exactly rocket science; VMS did it back in the early 80s. JVMs > could do a really nice job of this, noticing which monitors cause > contention and how long they tend to be held. A shame they don't. A higher priority could reduce the problem, but would not eliminate it. Arne PS: I thougth DECThreads came with VMS 5.5 in 1991- |