Suggestions for resolving threading problems in Java programming languages

Allen Holub points out that the threading model of the Java programming language may be the weakest part of the language. It is completely unsuited to the requirements of the actual complex program and is not object oriented at all. This article recommends significant modifications and additions to the Java language to address these issues.

The Java language threading model is one of the most difficult and satisfying parts of the language. Although the Java language itself is a good thing to support threading programming, it has too little support for threading syntax and class packs, and can only be applied to a very small application environment.

Most books on Java thread programming proving the flaws in the Java threading Model and provide a first-aid kit (Band-aid/Bundy Band-Aid) class library to address these problems. I call these types of first-aid kits because the problems they solve are supposed to be contained in the Java language's own syntax. In the long run, the syntax rather than the class library method will produce more efficient code. This is because the compiler and the Java virtual device (JVM) can tune program code together, and these optimizations are difficult or impossible to implement for code in the class library.

In My taming Java Threads (see Resources) book and in this article, I further recommend that you make some modifications to the Java programming language itself so that it can really solve these threading programming problems. The main difference between this and my book is that I've been thinking more about writing this article, so I've improved on the proposals in the book. These suggestions are only tentative--only my personal thoughts on these issues, and the realization of these ideas requires a lot of work and peer evaluation. But this is a beginning after all, I intend to solve these problems to set up a dedicated working group, if you are interested, please send e-mail to threading@holub.com. I will send you a notice once I have really started.

The proposals put forward here are very bold. Some people recommend subtle and minor modifications to the Java Language Specification (JLS) (see Resources) to address the current fuzzy JVM behavior, but I want to make a more thorough improvement.

In the actual draft, many of my suggestions include introducing new keywords for this language. While it is often true that the existing code for a language is not required to break through, it must be able to introduce new keywords if the language is not to remain unchanged and obsolete. In order for the imported keyword to not conflict with the existing identifier, I will use a ($) character, which is illegal in the existing identifier, after careful consideration. (for example, use a $task instead of a task). The compiler's command-line switches are required to support the use of these keyword variants instead of ignoring the dollar sign.

The concept of task (tasks)

The fundamental problem with the Java threading model is that it is not object oriented at all. Object-oriented (OO) designers do not consider problems at all in a threading perspective; they are considering synchronous information asynchronous information (the synchronization information is processed immediately – the message handle is returned until the information processing is complete, and the asynchronous message is processed for a period of time in the background after it is received-and the message handle is returned long before the information processing is finished). The Toolkit.getimage () method in the Java programming language is a good example of asynchronous information. The message handle of the GetImage () is returned immediately without having to wait for the entire image to be retrieved by the background thread.

This is an object-oriented (OO) approach. However, as mentioned earlier, the Java threading model is object-oriented. A Java programming language thread is actually just a run () process that calls other procedures. There is no object, asynchronous or synchronized information, and other concepts here at all.

One solution that has been discussed in depth in my book is to use a active_object for this issue. An active object is an object that can receive an asynchronous request and is processed in the background for a period of time after the request has been received. In the Java programming language, a request can be encapsulated in an object. For example, you can pass an instance of a Runnable interface implementation to this active object, and the Run () method of the interface encapsulates the work that needs to be done. The Runnable object is discharged into the queue by this active object, and the active object uses a background thread to execute it when it is its turn to execute.

Asynchronous information that runs on an active object is actually synchronized because it is fetched and executed sequentially from the queue by a single service thread. Therefore, using an active object in a more procedural model can eliminate most synchronization problems.

In a sense, the entire SWING/AWT subsystem of the Java programming language is an active object. The only safe way to send a message to a swing queue is to invoke a method similar to Swingutilities.invokelater (), which sends a Runnable object on the Swing event queue, and when it is its turn, swing The event-handling thread will process it.

So my first suggestion is to incorporate the concept of a task (task) into the Java programming language so that the active object is integrated into the language. (The concept of task is drawn from Intel's RMX operating system and the Ada programming language.) Similar concepts are supported in most real-time operating systems. ）