Advertisment

JProbe Threadalyzer

author-image
PCQ Bureau
New Update

JProbe Threadalyzer (ServerSide Edition), written in Java, can be a lifesaver for debugging deadlocks, race conditions, and stalls in multi- threading. It displays a comprehensive, graphical report after analyzing a multithreaded Java program. The version we reviewed, Threadalyzer 3.0.0, could analyze code on one machine, and display the results on a remote machine. It has a friendly GUI interface customizable to SDI (single document interface) or MDI (multiple document interface).

Advertisment
  • Price: Rs 58,800
  • Meant for: Programmers
  • Features: Graphical report of threading problems; analyzes applets

    JSPs, servlets, EJBs
  • Contact: Bunka Orient India. Tel: 011- 6463654, 6463661. Nehru Enclave, New Delhi 110019.

    www.boi.co.in
  • E-mail: sales@boi.co.in

Deadlocks: They occur in badly synchronized methods, wherein executing threads wait for each other to release locks on synchronized methods. Threadalyzer immediately detected a deadlock in our test program correctly.

Threadalyzer uses colored icons to depict various states of the threads. You can read the actual problem, and also go to the actual lines of code where it happened. Apart from sure deadlocks, you can configure Threadalyzer to report situations that may lead to deadlocks, using its configuration menu item called JProbe

LaunchPad. 

Advertisment

Thread stalls: They usually occur when a thread is paused by calling the wait( ) method. Such a thread usually resumes its execution when another thread calls the notify() method. In our second code we called the wait( ) method for the threads but never called the notify( ) method. This gave rise to a thread stall and was detected by the Threadalyzer. Using the JProbe LaunchPad, you can also specify the number of seconds a thread is paused to declare it a ‘stalled’ thread. Additionally, you can opt for detecting system level stalls, say, in the JVM threads.

Race conditions: Race conditions or data race usually occur when there is no ordered way for threads to access shared (between threads) data, leading to possible data corruption and unpredictable results. These conditions can be overcome by declaring methods as ‘synchronized’, which change the value of data variables. To simulate a race condition we fed Threadalyzer with code where threads change the value of an instance variable not declared synchronized. Threadalyzer found the problem and reported two data race conditions: ‘Happens Before’ and ‘Lock Covers’. Explanations for both were given in ‘Help’, and we could again access the lines where the problem occurred.

A snapshot of the reports displayed can be taken and saved as text or HTML, to view later. We found Threadalyzer’s user interface slows down when analyzing multiple conditions on a large application. This trade off is also indicated graphically at the bottom of the launchpad. Threadalyzer can also analyze Java applets, JSPs, servlets, and EJBs. The application comes with comprehensive help and gives explanations with examples. But at one place, the help referred to some examples, which weren’t actually there.

Shekhar Govindarajan

Advertisment