Letters

Dear DDJ,

I read with interest Allan Vermeulen's article "Java Deadlock" (DDJ, September 1997). Allan is only partly right when he says that deadlock is "a condition where all of the threads have stopped and are waiting for each other." ("Stopped" in the daily meaning of the word, I assume, not Java's.) Deadlock is a mutual starvation between at least two threads that can't satisfy each other. The rest of the threads may run for weeks, until the service of one of the threads engaged in the deadly embrace is required. The final result could be as Vermeulen states, but it doesn't have to -- with tens of threads it is unlikely that they all will be part of the circle of threads waiting for each other.

Controlling deadlock in Java doesn't have to be some sort of black art. Instead of Hoares monitor (that the Java language offers), we can make monitors invisible and use Hoare's later CSP on top of them. Have a look at the CSP-library under development: start at http://www.hensa.ac.uk/parallel/groups/wotug/java/discussion/. The library simulates occam semantics (occam is a safe multithreading programming language), a proven multithreading solution during the last ten-15 years. Using this library and a set of rules, you can avoid deadlock for sure. If you specify the same system in textual CSP, you may run a deadlock checker that doesn't let deadlock pass! (Start at http://www.comlab.ox.ac.uk/archive/csp.html.)

Oyvind Teig
Autronica, Norway
[email protected]

Java JNI

Dear DDJ,

I was glad that you published "The Java Native Method Interface and Windows," by Andrew Wilson (DDJ, August 1997) and I found that, up until the last paragraph, it was very well written. The article did a very good job at describing the interface and I felt that I had a strong understanding of its operation after reading it.

I do, though, have concerns over the last paragraph which states: "...This makes it possible to write large scale applications in Java, while keeping the system-dependent function implementations native to the operating system."

The most important aspect of Java isn't its usefulness on the Internet due to its compactness and security features -- it is the potential that exists to have widespread availability of software written in a portable language. The reason users are locked into certain operating systems is that there are so many more applications available to run on them. If the majority of software was completely portable, then it would remove this impediment from the growth of the software industry.

As soon as we use JNI to implement application-specific requirements, it really negates the main purpose of using the Java language in the first place.

JNI is still an important development in Java because it allows the language to grow and expand much more freely than otherwise. We all realize that certain functions must be performed by accessing the operating system directly. The current class library for Java cannot possibly cover all of these situations. If it weren't for JNI, then every time a new requirement is identified that requires direct access to the operating system, we would be dependent on the powers that manage the class library to update it and the various companies who have implemented a virtual machine to implement the new functionality.

I would like to see a standard developed which allows the development of the equivalent of JavaBeans but using JNI. It would be much more complex because, once the API is defined, one would have to get developers on board to implement the API on the various operating systems.

Greg Cooper
Pixel Productions
[email protected]

Cubic Spline Correction

Dear DDJ,

I have received notice about problems encountered with the code in my article "A Cubic Spline Extrema Algorithm" (DDJ, April 1996). Peter Hengel pointed out that the code had an off-by-one error in a routine. He was correct. I have since provided the corrections to several users of the code who have contacted me. Others who might have a very forgiving compiler, such as I did at the time, would not have noticed any problem. However, I finally got around to providing the fixes to the code: If cubic_io.c is being used to get the data, the line that decrements num_pts by one in main() should be removed. This caused the algorithm to think there was one less point than was really available -- although the algorithm still yields very good results!

In cubic_extrema.c, ComputeSecDerivs() should have another member of the diag array allocated (for instance, num_pts-1 instead of num_pts-2) and all uses of a diag index should be incremented by 1 (change diag[i-1] to diag[i], for example).

These changes have since been "field tested" and all users have indicated excellent results. Note that the algorithm is untouched -- only the implementation. I hope these errors did not inconvenience anyone. Additionally, I can electronically provide all the article test case data to anyone wishing to stress test the implementation.

Mike Courtney
[email protected]

Editors Note: The two corrected files, header file, and input test data files (concatenated) Mike refers to are available electronically; see "Resource Center" on page 3.

Learning C++: Minute to Minute

Dear DDJ,

I am writing to thank Al Stevens for mentioning my book, Teach Yourself C++ In 21 Days, second edition, in his September 1997 column. While he "deprecated" the idea of learning C++ in 21 days, and I'm sure he would be even more amused by my new book, Teach Yourself C++ In 24 Hours, I am reminded of the Steve Wright joke about asking a store owner why he was closed when the sign said "Open 24 Hours." "Well," he said, "not in a row."

I certainly agree with Al that it takes more than 21 calendar days to learn as powerful and complex a language as C++ -- which is why I include a quiz and exercise section, to allow students the opportunity to master each lesson before moving on. The goal of my book, and most primers, is to provide a solid foundation on which the student can build for many months and years.

In any case, I continue to enjoy Al's writing, and embrace his idea of selling the Teach Yourself C++ collection on QVC. "Plus, if you order now, you can have the kitchen knives for free."

Jesse Liberty
[email protected]

Kahan Kudos

Dear DDJ,

Your November 1997 interview with Prof. William Kahan was excellent! As a chemical engineer and developer of mathematical software, Prof. Kahan's comments on exception handling and C++ compilers were encouraging to my development efforts.

I appreciated Prof. Kahan's input about what really happens when optimized code runs on an Intel machine and I hope he will comment in more detail about the PowerPC CPU floating-point accuracy and performance. I look forward to more detailed articles regarding numerical programming.

John A. Jackson
LWE Research Inc.
[email protected]

Dear DDJ,

I enjoyed the interview with William Kahan. As a Cobol programmer, I seldom have to deal with numerical analysis. Recently, however, I was stung by some things Kahan mentioned. Dividing by zero doesn't work too well on IBM mainframe Cobol. I had some code that didn't check if the divisor was zero, and had an abend with S0CB message, or divide by zero error. The workaround was similar to what Dr. Kahan suggested:

IF WS-SHIFT-HOURS GREATER ZERO COMPUTE
  WS-OPERATION-TIME = WS-QUEUE-TIME / WS-SHIFT-HOURS

END-COMPUTE

ELSE

MOVE ZERO TO WS-OPERATION-TIME

END-IF

The if check stopped the abend. But then, the program had other problems. I accessed an array with subscript equal to 0, which isn't good in Cobol because subscripts valid values start with 1. I accidentally retrieved the contents of a variable behind the array in working storage. Thus, users ended up with asterisks and spaces in what was supposed to be a numeric field. This was fixed by checking that the subscript had a valid value:

IF WS-SUB GREATER THAN ZERO
  MOVE TABLE-ELEMENT (WS-SUB) TO WS-RESULT

ELSE

  MOVE LI-DEFAULT-VALUE  TO WS-RESULT

END-IF

Chris Mason
Cupertino, California
[email protected]

Custom Draw

Dear DDJ,

There is an easier way to implement custom drawing of Tree View items that Jason Clark presents in his article "Customizing Common Controls" (DDJ, September 1997).

For little over a year now, Microsoft's COMCTL32.DLL has supported a feature called "Custom Draw." While a Tree View control, List View control, or any of the "new" common controls is being drawn, it sends NM_CUSTOMDRAW notifications to its parent for each item being drawn. In a handler for this notification you can do a simple alteration, such as changing the font in which the item will be drawn, or as complex an alternation as drawing the whole item yourself.

To my mind, this solution is superior to Jason's because it is documented, works with the current (and future) COMCTL32.DLL, and requires that you only handle one notification message.

Custom Draw is a relatively new feature, not documented in the original Win32 SDK. This information was originally in the ActiveX SDK. I guess it's now either in the Platform SDK or the Internet Client SDK, both available from the Microsoft's web site.

Dejan Jelovic
[email protected]

DDJ welcomes your comments and suggestions. Send letters to DDJ, 411 Borel Avenue, Suite 100, San Mateo, CA 94402-3522. We can also be reached via [email protected], [email protected], and by fax at 415-358-9749. Please state your name and address. DDJ reserves the right to edit letters for length and content.

DDJ