Multithreading Applets—the Right Way

The canonical design of multithreaded applets is inherently flawed. You know what I’m talking about: the run method with the repaint/sleep statements embedded in a while(true). Any self-respecting operating systems instructor would fail that design with reckless abandon. Here’s the offensive code:

 public void run() {        while (true) {          repaint();          try {           Thread.sleep(100);          } catch (InterruptedException e) {}        }      } 

Of course, we also have a paint method somewhere, which does all our impressive applet drawing. What’s wrong with this model? The problem is in the sleep statement. Simply speaking, there is no perfect number to put in the sleep statement. The sleep statement is there to hold off calling repaint until we know the VM inside our browser (or appletviewer) completed a call to our paint method. Unfortunately, you can never anticipate how long that will take. That is dependent on the machine, OS, length of the paint method, and what else happens to be going on in the OS at the same time. Even if you found a number that seemed to work well, it may well fail if the OS gets busy with other transient functions, and it may be disastrous when moved to a less powerful machine.

The bottom line is that you are trying to synchronize two threads with that sleep statement. The two threads are your “run” thread and the thread the browser sends in to call your paint. That is synchronization on a “guess” (Dr. Tanenbaum, please forgive us). This is seriously wrong.

How can we solve this problem correctly? In other words, how can I guarantee that only one repaint is called for exactly one paint call? Try this:

 public synchronized void run() {        while (true) {          repaint();          try {           wait();           Thread.sleep(100); // optional          } catch (InterruptedException e) {}        }      }public void paint(Graphics g) {        // drawing        synchronized(this) {          notifyAll();        }    }

What have we done? If you follow the flow you’ll see that we issue a repaint and then wait. The run thread cannot continue until the paint method is done drawing and as its last act, notifies waiting threads. This paradigm guarantees one repaint per paint. We can still put in a sleep to control how much CPU a possibly overzealous applet may take, but it is by no means synchronizing the threads.

Share the Post:
Share on facebook
Share on twitter
Share on linkedin


The Latest

microsoft careers

Top Careers at Microsoft

Microsoft has gained its position as one of the top companies in the world, and Microsoft careers are flourishing. This multinational company is efficiently developing popular software and computers with other consumer electronics. It is a dream come true for so many people to acquire a high paid, high-prestige job

your company's audio

4 Areas of Your Company Where Your Audio Really Matters

Your company probably relies on audio more than you realize. Whether you’re creating a spoken text message to a colleague or giving a speech, you want your audio to shine. Otherwise, you could cause avoidable friction points and potentially hurt your brand reputation. For example, let’s say you create a

chrome os developer mode

How to Turn on Chrome OS Developer Mode

Google’s Chrome OS is a popular operating system that is widely used on Chromebooks and other devices. While it is designed to be simple and user-friendly, there are times when users may want to access additional features and functionality. One way to do this is by turning on Chrome OS