Date: Sun, 16 Sep 2007 21:57:48 -0700 From: Alfred Perlstein <alfred@freebsd.org> To: Nick Johnson <freebsd@spatula.net> Cc: freebsd-java@freebsd.org Subject: Re: Massive performance loss from OS::sleep hack Message-ID: <20070917045748.GU79417@elvis.mu.org> In-Reply-To: <20070916182507.W82369@turing> References: <46EC1B55.4060202@FreeBSD.org> <200709152250.50879.kurt@intricatesoftware.com> <Pine.GSO.4.64.0709160030580.3591@sea.ntplx.net> <b1fa29170709152225x5a57a30fm7efbd6e331cfff28@mail.gmail.com> <Pine.GSO.4.64.0709161128520.5797@sea.ntplx.net> <20070917005912.GT79417@elvis.mu.org> <20070916182507.W82369@turing>
next in thread | previous in thread | raw e-mail | index | archive | help
* Nick Johnson <freebsd@spatula.net> [070916 18:30] wrote: > On Sun, 16 Sep 2007, Alfred Perlstein wrote: > > > > Thread.yield() could first lower the current thread's priority to > > > the next used priority and then yield, raising the priority back after > > > the yield. This isn't perfect, there are race conditions, the next > > > highest priority thread(s) could be blocked and not runnable, etc. > > > Maybe just lowering the priority to min or default priority would work > > > well enough. > [snip] > > I think your suggestion about temporarily lowering priority > > makes sense. > > That sounds sane to me... if the JVM also keeps track of the fact of > another thread's having executed, one could lower the priority of the > thread to some minimum value, and then only raise it again once another > thread managed to execute... it seems like that would roughly recreate the > behaviour they're looking for. > > (Although maybe just dropping it to the minimum possible priority and then > restoring the priority the next time the thread ran would be sufficient to > prevent the deadlock? Perhaps an absolutely minimum priority value could > be reserved for threads from which this yielding behaviour was needed so > in case there were other threads that also had a low priority, they'd > still have a higher priority than the thread being asked to yield?) You second suggestion makes more sense as I would guess that the intent is to lower the priority until the next quantum. The second part of your second suggestion is not 100% needed (although it may be helpful) as the scheduler will appopriately run another thread and they will then contend at that lower level. -- - Alfred Perlstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070917045748.GU79417>