9

I have a Thread that only has to work when a certain circumstance comes in. Otherwise it just iterates over an empty infinite loop:

public void run() {
    while(true) {
        if(ball != null) {
             // do some Calculations
        }
    }
}

Does it affect the performance when the loop actually does nothing but it has to check if it has to do the calculation every iteration? Only creating a this Thread when needed is not an option for me, because my class which implements Runnable is a visual object which has be shown all the time.

edit: so is the following a good solution? Or is it better to use a different method (concerning performance)?

private final Object standBy = new Object();

public void run() {
    while(true) {
        synchronized (standBy) {
            while(ball != null)  // should I use while or if here?
                try{ standBy.wait() }
                catch (InterruptedException ie) {}
        }
        if(ball != null) {
             // do some Calculations
        }
}

public void handleCollision(Ball b) {
    // some more code..
    ball = b;
    synchronized (standBy) {
        standBy.notify();
    }
}
SimonH
  • 1,385
  • 15
  • 35
  • 2
    Use a `BlockingQueue`; this infinite loop will eat all your cpu time. – twentylemon Jun 13 '15 at 21:13
  • 1
    There is no circumstance in which this thread does not work. It's always doing work. – David Schwartz Jun 13 '15 at 21:13
  • 1
    Does your computer have a spare processor? If you have enough processors, a continuously runnable thread is cheap. If not, it costs you. – Patricia Shanahan Jun 13 '15 at 21:32
  • See also: http://stackoverflow.com/questions/8409609/java-empty-while-loop – assylias Jun 13 '15 at 22:24
  • In addition to needlessly burning CPU time, your first code example is incorrect: Changes done by other threads are only guaranteed to be visible if some kind of synchronization action established a happens-before relationship between the threads. Your code may therefore fail to detect that `ball` has been set. – meriton Jun 14 '15 at 13:49

5 Answers5

9

You might want to consider putting the thread to sleep and only waking it up only when your 'ball' variable becomes true. There are multiple ways of doing this, from using the very low level, wait and notify statements to using the java.util.concurrent classes which provide a less error prone way of doing this. Have a look at the documentation for the condition interface. A data structure like a BlockingQueue would also be a solution.

Cosu
  • 578
  • 3
  • 8
8

Yes it does. This is the most simple implementation of busy waiting, and should be avoided whenever possible. Use wait/notify or java.util.concurrent mechanisms. Maybe you should be more specific about what exactly you want to achieve to get more useful responses.

SqueezyMo
  • 1,606
  • 2
  • 21
  • 34
3

Yes, it will certainly affect performance. To increase performance, you can consider putting in a bit of a time delay (say 500ms or 1000ms or even higher) in your code depending how crucial timing is to you.

kojow7
  • 10,308
  • 17
  • 80
  • 135
3

Share a BlockingQueue between your threads. 

 class Producer implements Runnable {
   private final BlockingQueue queue;
   Producer(BlockingQueue q) { queue = q; }
   public void run() {
     try {
       while (true) { queue.put(produce()); }
     } catch (InterruptedException ex) { ... handle ...}
   }
   Object produce() { ... }
 }

 class Consumer implements Runnable {
   private final BlockingQueue queue;
   Consumer(BlockingQueue q) { queue = q; }
   public void run() {
     try {
       while (true) { consume(queue.take()); }
     } catch (InterruptedException ex) { ... handle ...}
   }
   void consume(Object x) { ... }
 }
twentylemon
  • 1,248
  • 9
  • 11
1

I found the following interesting thing. In task manager, running that infinite loop like that, would consume 17% of my CPU. Now, if I added a simple

Thread.sleep(1)

inside the loop, which is only one milisecond, the CPU use dropped to almost zero as if I was not using the program, and the response time of the program was still pretty good on average (in my case it needed to reply things fast)

Sfp
  • 539
  • 4
  • 15