3.3 Background

< Day Day Up >

Chapter 2 gave an overview of the facilities in Java for implementing concurrency, as well as some of the common problems that are unique to concurrent programs; however, explaining the mechanisms of concurrency is not sufficient for many programmers learning concurrency. Most programmers have been taught to understand programs as procedural entities — programs start at the first line in main and proceed in a stepwise fashion through the program, executing each statement in its logical order. In addition, programmers are taught that a program is totally ordered, that the execution of the program is deterministic in regard to the order in which statements are executed, so that each time the program is run it produces exactly the same results. So, while some programmers might understand that concurrent programs do not behave procedurally, they do not understand how to structure a program effectively to take advantage of concurrency. This became apparent me when I first started teaching concurrent programming in Java, as many students would attempt to write programs that would control the threads using the suspend, stop, and resume methods, rather than allowing the interactions between the threads to solve the problem.

The purpose of this chapter is to help programmers experienced in procedural programming to understand how to structure and create a concurrent program. The reader should be warned that this is often a very difficult undertaking that may require changes in the way one reasons about a program. It is not uncommon for programmers to say that they could not understand how the methodology in this chapter worked, and they simply implemented programs according to the rules laid out in the chapter. But, once a program works, the material seems trivial and they cannot understand why they had a problem with it.

The techniques presented in this chapter involve creating ensembles, which are collections of objects that coordinate with each other to solve a problem. Creating ensembles involves breaking a problem down into two types of objects, active and passive. Active objects implement procedural code running in threads. Passive or reactive objects do not perform actions except as a result of a request from an active object, and they control the interactions between the active objects. Passive objects are designed using state diagrams, and then are mechanistically translated into Java code.

< Day Day Up >