Thread.yield() doesn't do what most think it does

Performance Tuning
#1

Thread.yield() will only work if there are other threads with the same priority otherwise the request is ignored.

All the well designed timers use the yield command in conjunction with a high precision clock, the problem with that is you will not be able to fix your framerate if your thread is the only one running with the same priority.
The issue hasn’t occured as of yet because even if you don’t use AWT/Swing there are other things running behind the scenes but what happens if in future all these things were no longer required and the only thread running is your own?

Everytime you load your game it will load it’s own instance of the JVM, if you aren’t using Swing/Awt then the only thread running will be your own and your timer will not work.

Other than going straight to JNI or using sleep(because it’s innacurate) what other alternatives are there to Thread.yield()?

#2

There are no other alternatives. And FYI, Thread.yield() works fine under any normal gaming circumstances although I personally find Thread.sleep(0) to be slightly better.

Cas :slight_smile:

#3

AFAIK the minimum you can sleep for is dependent on the OS.
Windows XP = 10ms.

Thread.sleep(0) will sleep for 10ms under XP, 50ms under 98 and I’m not sure but probably wont sleep at all under Linux.

Do you use sleep(0) instead of yield in your games?

#4

I do now, as I discovered that a busy yield() loop uses so much CPU (albeit “kindly”) on my laptop it triggered the heat sensor and clocked down the processor :frowning:

A busy sleep(0) seems to work just as well for my games.

Cas :slight_smile:

#5

I think I’m going to have to eat my words yet again.
Thread.yield() as of Java 5 should be deprecated.

[quote]Nanosecond-granularity timing: The new java.lang.System.nanotime() method that provides high-precision timing facilities has been added to enable access to nanosecond-granularity time source for making relative time measurements, and methods that accept timeouts such as BlockingQueue.offer(), BlockingQueue.poll(), Lock.tryLock(), Condition.wait(), and Thread.sleep(). Note that the precision of nanotime() is platform-dependent.
[/quote]
You should take note that Thread.sleep() has NS accuracy.
I suggest you try Thread.sleep(1) for more appropriate results Princec. :wink:

http://java.sun.com/developer/technicalArticles/J2SE/concurrency/

#6

Sorry I was in fact talking out of my arse :slight_smile: I do use sleep(1), not sleep(0).

Cas :slight_smile:

#7

I’m wondering if using Thread.sleep(1) might not starve the CPU if for example the GC has significant work to do or hotspot is doing intensive optimizations/compilations? This might not be significant on recent or fast systems but maybe not on older ones.

#8

On any non-realtime OS (read: any desktop OS) sleep(mills) and its varients specify the minimum amount of time to sleep for. The OS can quite happily keep your thread dormant for much longer if some other process - such as the GC - is keeping it plenty busy.