We've just published a new article, Dibyendu Roy's "Rethinking Multi-Threaded Design Principles". Multi-threaded software engineering continues to gain attention from new audiences as the developer and management communities come to recognize the significance of the Multicore Challenge.
The history of software and hardware has been one of ever increasing speed, memory, and software capability. The speed aspect is where we now face a problem. Increases in speed were historically tied to new technologies that enabled successful utilization of ever thinner chips. The problem today is that we're down to a rather small number of atoms. Since we can't shrink atoms themselves, it's a considerable technological challenge to make an individual chip faster. What can be done, however, is to put more cores on an individual chip, thus multipling the amount of work a single chip can perform, even though the processing speed of an individual core remains unchanged.
While this strategy is a challenge for chip manufacturers, ultimately (when the typical home or small office machine starts having 8 or 16 cores) it will be an even bigger challenge to software firms: in order to make their applications run faster, they'll have to write the software in a threadsafe manner that also utilizes multiple threads for the major processing-intensive operations.
Multithreaded programming has been around for a long time in Java. The addition of closures to Java 7 may indeed facilitate new forms of multithreading development in the future. But, the capability to develop multithreaded software exists today. The ways developers can take advantage of today's multithreading capability is what Dibyendu covers in his article. While Dibyendu's example is on the server side, the principles he discusses can be applied to server-side development or for developing applications that will efficiently utilize multiple cores on client machines:
For many years, we have been using Java Threads for developing numerous Client-Server based applications. While it's always desirable to have a highly responsive Client application, handling a high volume of client requests has always been a prime goal of any Server application. However, designing a highly-scalable server requires lots of analysis. Without careful design and adherence to a well thought out underlying policy, a thread based system can fail to produce the desired outcome.
In this article, we'll discuss certain design principles that should be followed when the objective is to build an efficient, thread-safe application.
Dibyendu walks us through an example application, talking about the problems that come with multithreaded development, such as thread delegation, single thread confinement, and synchronized locking. He concludes:
Designing and improvising a thread based application is a challenge. But by following certain design principles and guidance, this can be easily overcome. At the same time, clear understanding of thread safety policy is also essential as it helps you simplify the design. There are many other techniques available that we couldn't cover here. However, the principles presented here will always assist you in overcoming some of the thread safety related hurdles you might be facing as you develop thread-safe applications intended for operation on modern multicore and multiprocessor computers.
In Java Today, the latest Oracle TechCast Live broadcast is JavaFX -- Just Getting Started. The just under 26 minute video features Oracle Technology Network leader Justin Kestelyn interviewing Nandini Ramani. An audio-only rendition is also available. Terrence Barr blogged about the TechCast:
This just out: Nandini Ramani, Director, Java Development Group, Oracle talks with Justin Kestelyn, Senior Director, Oracle Technology Network, about JavaFX innovation, evangelism, and adoption...
For those of you who still don’t know Bean Validation, you should check the JSR 303 and the documentation of the reference implementation Hibernate Validator. In fact, like many other JSRs, Hibernate Validator existed on its own for quite a long time as an open source project (until version 3.1.x) and then got specified under the JSR 303 and became the reference implementation from its version 4.x. Bean Validation 1.0 was born and is now part of Java EE 6. But keep in mind that Bean Validation doesn’t need Java EE 6 to run (like other specs such as JPA 2.0, JSF 2.0, CDI 1.0…) and can be used outside any container...
I just added allow_weak_crypto support in OpenJDK. With this property set to false, des-cbc-md5 and des-cbc-crc etypes are not supported, even if you include them i permitted_enctypes or default_{tkt|tgs}_enctypes settings...
At the very beginning of my full time programmer career, when I worked at Silicon Graphics, Larry Wall and Randal Schwartz gave a brown bag session about their now legendary camel book. Naturally, I had them sign my copy, the front page of which I proudly display at left. Notice the “There’s More Than One Way To Do It!” stamp at the top. For better or worse, Perl is famous for this property. Less famous (or perhaps even infamous) for having more than one way to do it is JSF...
Talking about messaging imply two basic functionalities which all other provided features are built around them; these two capabilities include support for topics and queues which basically lets a message to be consumed by as many interested consumer as subscribed or at just one of the interested consumer(s). Messaging middleware was present in the industry before Java come along and every one of them had its own interfaces for providing the messaging services. There were no standard interfaces which vendors try to comply with it in order to increase the compatibility, interoperability, ease of use, and portability. The art of Java community was defining Java Messaging System (JMS) as a standard set of interfaces to interact with this type of middleware from Java based applications...
I woke up the other day and realized its 2010. When I was a kid, year 2000 was far, far away (well not quite, but hey when you are 7 years old 13 years is a long time). In 2001 we were supposed to be colonyzing the moon. In 2010, Jupiter would be within our reach. And there are reliable reports indicating that 9 years from now flying cars and aritificial life forms should be common place. I must admit: the kid within me feels kind of disappointed. On the other hand...
In the Forums, noelkoffi has a GlassFish question, EAR application deployment: Message Driven Beans can't be Managed Beans: Hi All, We are currently facing a severe bug or deploymrnt issue with Glassfish v3 when trying to deploy an EAR Application that deals with Netbeans 6.8 and EJB 3.0. The error that comes out is the following : GRAVE: Exception while...
In the Java SE forum, ranjithjavanet asks if HttpURLConnection setReadTimeout is broken?: Using: jdk1.6.0_17. I am trying to develop something that can track an HTTP URL for availability. I was almost ready to use Apache's http client library then I suddenly noticed that since 1.4 Java net API has setReadTimeout on...
We just published a new java.net Feature Article, Dibyendu Roy's Rethinking Multi-Threaded Design Principles; in the emerging multicore/multiprocessor world, multi-threaded programming is critical, in my view. We're also featuring Has JDBC Kept up with Enterprise Requirements? by Jesse Davis; in the article, Jesse invites us to look beyond Type 4 architecture to address the latest requirements of the enterprise Java ecosystem. And, Adhir Mehta's Java Tech article, Web Service Simulatino Using Servlets also remains in the Featured Articles section of the java.net home page.
Registered users can submit event listings for the java.net Events Page using our events submission form. All submissions go through an editorial review before being posted to the site.
Archives and Subscriptions: This blog is delivered weekdays as the Java Today RSS feed. Also, once this page is no longer featured as the front page of java.net it will be archived along with other past issues in the java.net Archive.
Previous Topic
