CS150 Lecture 24, 11/10/00:  Race Conditions and Applets

Need Extra Credit? 

There is a Midterm #1 Extra Credit problem available.   See Prof. Wong to obtain it.   Due date:  9:00 AM Wed. 11/15/00.

Exam Review Now On-line!

See the following lectures.

Race Conditions in Threads

A "race" condition occurs when two or more threads are competing for the same resources and erroneous behavior results because each thread is unaware of what the other threads are doing to those resources.

Example:  Multiple threads updating a common counter object.

Suppose we had a single counter object with an increment() method.  Let's also suppose that this increment() method took a significantly long time to execute, that is, a time longer than the time slice normally allocated for a thread.   

Thus, multiple threads may attempt to access the counter while any other thread is still executing the increment() method.  If they do, they will obtain the wrong value for the counter's present count and thus will increment the counter incorrectly.

We need method synchronization to keep other threads from accessing the counter object.    Thus only one thread at a time will be using the counter.

Get the demo code here. 

Without synchronization:  counter may not count properly and not register the proper number of increments.

With synchronization:  counter runs slower, but accurately.

Applets

1. See JavaResources
2. Example applet and demo code and modified Frame1.java
3. Called from HTML.   Can communicate with the web page.
4. Most browsers won't run Java 2 applets!   Must use Appletviewer (or run inside of IDE).
5. Appletviewer runs the HTML page.
6. Applets are client-side applications. 
7. Applets are easy to deploy to the user--no fancy installation needed...well almost....you still need to install the Java plug-in on every user, but after that, life is supposed to be easy...yeah.
8. Differences between applets and  applications
   1. No main()
   2. No parameterized constructor
   3. Initialization done in init() -- runs only once.
   4. Stays in memory
      1. Classes are loaded only once, even if the user browses to another page and then comes back. 
      2. start() method -- runs each time the web page is accessed.  
      3. stop() method -- runs when the user goes to another web page.   Neither IE nor NEtscape appear to be calling the stop() method properly though.   Init() appears to be run every time.  :-( 
   5. Security restrictions -- the "sandbox" -- security restrictions.  E.g. no access to local machine, no files from different servers, etc.
9. JBuilder applet tips:
   1. Getting the codebase correct:  If your project is saved inside of one of the packages in the project, JBuilder may get the applet codebase incorrect.  The codebase is the default Java package directory, which is the directory just above all the packages.   JBuilder will put the HTML web page in the same directory as the project and may incorrectly set the codebase (look in the HTML code) to "." instead of  "..".  
   2. Running an application from an applet:  Just instantiate the frame and call its show() method.   To keep the whole browser from closing when the frame closes, add a new constructor to the frame that takes a boolean value, called for instance, "isApplet".   A boolean property, isApplet should be initialized with the value "false".  The new constructor should call the original constructor and set the isApplet property's value.  Add the expression "!isApplet && " to the conditional statement inside the processWindowEvent() method where the code to exit the system resides.   Thus when the applet instantiates the frame, it should use the constructor that takes the boolean and give it the value "true".    E.g. (new Frame1(true)).show();