Research on Java Threading Model defect

The threading model of the Java programming language may be the weakest part of this 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.

Allen Holub points out that 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. ）

A task has a built-in active object distributor and automatically manages all the mechanisms that handle asynchronous information.

Defining a task is basically the same as defining a class, except that you need to add a asynchronous modifier to the task's method to indicate that the assignment program for the active object handles these methods in the background.

All write requests are queued in the Active-object input queue with a dispatch () procedure call. Any exceptions (exception) that occur when processing these asynchronous information in the background are handled by the Exception_handler object, which is passed to the File_io_task constructor.

The main problem with this class based approach is that it's too complex--for a simple operation like this, the code is too miscellaneous. After introducing the $task and $asynchronous keywords into the Java language, you can rewrite the previous code as follows:

Note that the asynchronous method does not specify a return value because its handle is returned immediately, rather than waiting for the requested operation to be processed. Therefore, there is no reasonable return value at this time. For derived models, $task keyword and class are the same: $task can implement interfaces, inheriting classes, and other inherited tasks. Methods marked with the asynchronous keyword are processed by the $task in the background. Other methods will run synchronously, just as you would in a class.

$task keyword can be decorated with an optional $ERROR clause, as shown above, which indicates that there will be a default handler for any exception that cannot be caught by the asynchronous method itself. I use $ to represent the exception object being thrown. If you do not specify a $error clause, a reasonable error message (probably stack trace information) is printed.

Note that in order to ensure thread safety, the parameters of the asynchronous method must be invariant (immutable). The runtime system should ensure this invariance through relevant semantics (simple replication is usually not sufficient).

All task objects must support some pseudo information (pseudo-message).

In addition to the commonly used modifiers (public, and so on), the Task keyword should also accept a $pooled (n) modifier, which causes the task to use a thread pool instead of running an asynchronous request with a single thread. n Specifies the size of the desired thread pool, which can be increased if necessary, but should be shrunk to its original size when the thread is no longer needed. Pseudo-Domain (Pseudo-field) $pool _size returns the original n parameter value specified in $pooled (n).

In the eighth chapter of The Taming Java Threads, I give a server-side socket handler as an example of a thread pool. It is a good example of a task that uses a thread pool. The basic idea is to produce a stand-alone object, its task is to monitor a server-side socket. Whenever a client connects to the server, the server-side object crawls a predesigned sleep thread from the pool and sets the thread to serve the client connection. The socket server will produce an additional customer service thread, but when the connection is closed, the additional threads will be removed.