Date: Thu, 8 Aug 2002 13:08:08 -0700 (PDT) From: Nick Johnson <freebsd@spatula.net> To: Bill Huey <billh@gnuppy.monkey.org> Cc: freebsd-java@freebsd.org Subject: Re: Thread.sleep implementation Message-ID: <20020808130530.K13773-100000@turing.morons.org> In-Reply-To: <20020808190716.GA2757@gnuppy.monkey.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 8 Aug 2002, Bill Huey wrote: > On Thu, Aug 08, 2002 at 07:48:01AM -0700, Nick Johnson wrote: > > I've noticed that in threads which are trying to make locks or wait to > > retry on some failure condition, the JVM tends to suddenly begin using > > tons of CPU, despite the presense of a Thread.sleep() call inside the > > loop. > > > > What seems to also happen is starvation of the other threads, almost as > > though Thread.sleep were implemented as a busy loop (?). I'll try to come > > up with a test case for this. I bring it up here in case someone closer > > to the JVM's internals might know what I'm talking about... > > Under what threading model ? Green threads with the native JVM (not hotspot), although now I'm beginning to wonder if the problem is related more to my second post; this particular thread is using Lucene, and reliably causing the JVM to spin its wheels in the native method RandomAccessFile.length. I suspect the problem may actually be there. That's the trouble with threads :/ Nick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020808130530.K13773-100000>