Dr. Dobb's Journal November 2001
Dear DDJ,
In Service Pack 2 for Internet Explorer 5.5, Microsoft has unilaterally and silently disabled support for Netscape-style plug-ins. This is going to needlessly complicate life for organizations, such as mine, which have standardized on web interfaces for all new applications and have many remote users where we don't control the desktop environment or the user's choice of browsers (or browser versions) or even platforms (Macintosh or Windows). We test everything we deploy on both Netscape and IE, then we don't have to worry about what platform or browser the user prefers, within reasonable limits, and we don't have the support burden of installing native clients on the computers in users' private offices or homes and trying to fix the native clients when they break. Up until now, the fact that Netscape-style plug-ins have worked equivalently on both Netscape Communicator/Navigator and Internet Explorer has let us deploy some pretty interesting applications over the Web — ranging from ad hoc query tools to sophisticated medical image viewing and processing. I can't see any reason for Microsoft to have "desupported" Netscape plug-ins in this way (as well as disabling the next version of IE from working with any version of the JVM later than the one they currently use) except just to be nasty. There are no new technical issues, and the security risks are certainly minimal — the main virus problems we've had in the last few years have been ActiveX and Word macros, not browser plug-ins or Java applets. If Microsoft can't control a technology, it tries to freeze it out. It's hard for me to put much faith in Microsoft's claims about the openness of its support for .NET and XML when I see this kind of paranoid, illogical, customer-unfriendly behavior time after time from the organization.
Ray Duncan
Director, Technology and Architecture
Enterprise Information Systems
Cedars-Sinai Health System
Dear DDJ,
Douglas Reilly's article, "Threading & the .NET Framework" (DDJ, August 2001) neatly illustrates the problems with using events in Win32 and .NET, but he misses the reason why Microsoft has introduced the monitors that he mentions.
His code in Listing Five suffers from a type of a lost wake-up bug. The main thread that parcels out work could set the event twice or more before any of the worker threads succeed on a wait, thus waking up only one worker for more than one set of the event. In a real application this could be important.
Also, his assertion in the code comments that "...I will not try and set event again until thread is done with that section" is false. Immediately after returning from the wait the worker thread might be interrupted by the system scheduler and the main thread might execute and loop around to reacquire the lock.
These are typical of the errors in multithreaded code that often show up only under high-system loads, probably when you least want them to.
Monitors provide a tried and trusted pattern to avoid such problems. The key is that a monitor provides the ability to automically release the lock and enter the wait state and also to reacquire the lock on exiting the wait state. If you attempt to roll your own, all kinds of nasty things can happen because of that tiny gap between exiting the wait and acquiring the lock or releasing the lock and entering the wait.
Monitors have been provided for a long time in Java and also in POSIX threads (pthreads) as condition variables.
Duncan Harris
duncan@sapio.co.uk
Douglas responds: Duncan is indeed correct. I have inadvertently demonstrated the difficulty involved in creating multithreaded applications. The first problem he mentions, the possibility of setting the event more than once, was a consequence of my simplification of the code to remove some other code that I thought could be eliminated without harming the example. He is correct that as written, the event could in theory be set more than once.
As for the second problem mentioned, it is indeed possible that the code could be interrupted after the wait but before acquiring the lock. I had not thought of this at the time, and only realized that later. The solution is the Monitor object that I brushed off briefly in the article. In my defense, the .NET documentation at the time did not cover the System Threading.Monitor class very well, and did not make clear the advantage of the Monitor class over the others when waiting on an object. The solution to the code being interrupted between the wait ending and the lock being acquired is indeed the use of the Monitor object. Shame on me for not looking at other documentation on Monitor classes in other environments. Thanks again for taking the time to correct me. I do appreciate it.
Dear DDJ,
I enjoyed the article "Examining CORBA Interoperability," by Eric Ironside, Letha Etzkorn, and David Zajac (DDJ, June 2001).
CORBA is being used as an infrastructure technology in many real-world distributed systems applications, where performance and interoperability are very important. The interoperability experiments that the authors performed are interesting, but I would like to make some comments about their results.
Interoperability between CORBA products is a serious concern for many users of CORBA. For this reason, the CORBA Open Source Testing (COST) project (http://cost.omg.org/) was started under the auspices of the Object Management Group (OMG). COST aims to develop a set of tests to verify interoperability and compliance to CORBA standards. The tests being developed by COST are freely available in source-code form. When COST is completed, it would be interesting to see the results of further ORB interoperability studies with these tests.
I would like to take issue with one of the claims and statements made by the authors: "When the C++ TAO code was moved from Windows NT to Linux, we discovered that exception handling was not directly portable because the compiler used to compile TAO on Linux does not support native exception handling easily nor efficiently."
The difficult[ies] that the authors faced were due to the fact that C++ exceptions were not enabled by default in the Linux configuration of TAO. If they had enabled C++ exceptions by default before building their TAO ORB, they would have found that C++ exceptions work well under Linux with TAO. I use this configuration every day on many of my mission-critical projects. The fact that C++ exceptions were not enabled by default under Linux was a legacy configuration issue from Linux distributions about five years ago. Since this is not an issue in modern Linux distributions, the next major release of TAO, Version 1.2, will have C++ exceptions that will be enabled by default in the stock Linux configuration.
I would also like to comment on another of the author's statements "When the precompiled versions can be used, everything works well. However, when the ORBs must be recompiled, the process is complex and time consuming." There is some truth to this, but I have found recompiling ORBs such as MICO and TAO to be no more complicated than compiling other large-scale, real-world C++ applications. Many of the problems that the authors faced with some of the ORBs were due to the fact that they used interim beta versions (such as TAO 1.1.9) instead of stable, supported releases.
OCI (http://www.theaceorb.com/) is a company that provides stable releases of the TAO ORB in source and binary form for many platforms, including the platforms used by the authors. I have used the OCI supported version of TAO on some of my mission-critical CORBA projects, and have not encountered the problems that the authors encountered with the beta release, which they obtained from Washington University St. Louis, which are only supported on a best-effort basis, unlike the OCI releases, which are supported by a commercial organization. OCI's release of TAO also enables native C++ exceptions under Linux by default. Thanks again for a very informative article.
Craig Rodrigues
crodrigu@bbn.com
Dear DDJ,
With the advent of Java 2 Runtime Environment (J2RE) 1.4.0-beta, Java game programmers have access to a free set of libraries that include full-screen support, a 3D graphics engine, traditional 2D effects, music and sound effects support, and plenty of network support. And the cool part is that even though Java executes on a virtual machine, it really is possible to develop games that run at acceptable frame rates. For instance, check out one I recently wrote for fun: http://members.bellatlantic.net/~birken/meatfighteronline/.
After releasing the game, I discovered the sad reality of writing games for a "portable" language. Most people simple do not want to bother installing and configuring the latest J2RE and all those additional libraries needed to run decent Java games. Sun needs to develop an automated J2RE update mechanism similar to Windows Update (that is, critical downloads and optional libraries). Some platforms are still waiting for Version 1.4 to become available, such as for Mac OS X. On top of this, Java game programmers are still waiting for things as simple as joystick support.
SCEI and Sun recently announced an agreement to integrate Java capabilities into the PlayStation 2 by the end of 2001. Unfortunately for Java game programmers hoping to port their creations to this dedicated game machine, the support will be limited to network communication abilities only. Perhaps Microsoft's Xbox will offer more.
Michael Birken
o__1@hotmail.com
Dear DDJ,
Although it is refreshing to read an article from someone involved in the current effort to produce smart appliances (see "Object-Oriented Device Networking," by Michael Howard, DDJ, August 2001) who has apparently realized that having the refrigerator send its owner a frantic e-mail every second because the toaster is no longer responding to it is not likely to win public acceptance, people in this field still need to get out more. I will never own a telephone that can tell my TV or stereo to reduce volume so that I can talk to whatever telemarketer just dialed my number. Such calls are what answer machines or voice mail are for. Now, a stereo or TV that tells my telephone to not ring because something important is going on, that would be different.
Paul S. Person
pperson@ix.netcom.com
DDJ