From owner-freebsd-java@FreeBSD.ORG Mon Sep 17 01:30:17 2007 Return-Path: Delivered-To: freebsd-java@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B23D616A41B; Mon, 17 Sep 2007 01:30:17 +0000 (UTC) (envelope-from freebsd@spatula.net) Received: from turing.morons.org (turing.morons.org [208.96.51.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7C1EF13C458; Mon, 17 Sep 2007 01:30:17 +0000 (UTC) (envelope-from freebsd@spatula.net) Received: by turing.morons.org (Postfix, from userid 1001) id E94F617036; Sun, 16 Sep 2007 18:30:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by turing.morons.org (Postfix) with ESMTP id E623F17034; Sun, 16 Sep 2007 18:30:08 -0700 (PDT) Date: Sun, 16 Sep 2007 18:30:08 -0700 (PDT) From: Nick Johnson X-X-Sender: spatula@turing To: Alfred Perlstein In-Reply-To: <20070917005912.GT79417@elvis.mu.org> Message-ID: <20070916182507.W82369@turing> References: <46EC1B55.4060202@FreeBSD.org> <200709152250.50879.kurt@intricatesoftware.com> <20070917005912.GT79417@elvis.mu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-java@freebsd.org Subject: Re: Massive performance loss from OS::sleep hack X-BeenThere: freebsd-java@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 01:30:17 -0000 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?) Nick -- "Courage isn't just a matter of not being frightened, you know. It's being afraid and doing what you have to do anyway." Doctor Who - Planet of the Daleks This message has been brought to you by Nick Johnson 2.3b1 and the number 6. http://healerNick.com/ http://morons.org/ http://spatula.net/