The Calling Stack Basic Terminology

The second part of this description At the same time... may still seem a little unmotivated. Why do we need to be able to accept more than one document simultaneously? The reason is that our application is a distributed application. Network latency and partial failure can cause difficulties, as in the following scenario: Bob is working from home this morning on an important presentation. He puts the finishing touches on it, connects to the Internet, and sends the document to the company printer. He then heads out for lunch, planning to pick up the printed document later in the day. In this scenario, network latency can cause the printer to become unavailable for long periods of time. Bobs presentation is probably quite large. And sending it over the Internet, from a dialup connection, might take a long time. If we dont insist that the printer handle simultaneous connections, then while Bob is sending the document, the printer will be idle and not accept other documents. Not only do we have the feedback problems we mentioned earlier i.e., other clients dont have any idea when, and if, they will be able to submit documents, this is also an inefficient use of the printer. The partial failure scenario causes a similar problem. Bobs connection could go down for a little while before the printer server realizes anything is wrong. In which case, not only does the printer server not accept documents, it no longer receives Bobs print request. As you can see, the ability to service requests from more than one client, and to do so at the same time, is crucial in the world of distributed applications. And the way it is done is by the use of threads. [ 1] [ 1] Thread is shorthand for thread of execution. With the exception of overly z ealous undergraduates, very few people use the full name.

11.2 Basic Terminology

To understand threads, we need to step back for a moment and recall some basic ideas from computer science. In particular, we need to talk for a moment about the stack and the heap. Readers who feel comfortable with the basic concepts that underly threading might want to jump ahead to Sect ion 11.2.5 .

11.2.1 The Calling Stack

A stack is a data structure that serves as a container. You can insert and remove items from a stack. The only restriction is that the only item that can be removed is the item that was most recently inserted. Stacks are often visualized as a pile of items. You insert items [ 2] by placing them on the top of the stack; you can remove only the item on top of the pile. See Figur e 11- 2 . [ 2] These items are often called stack frames. I will use the terminology interchangeably. Figure 11-2. The calling stack While running, a program maintains a calling stack of methods that it is currently in. Consider the following code: private class GetBalanceAction implements ActionListener { public void actionPerformedActionEvent event { try { getAccount ; resetBalanceField ; releaseAccount ; } ..... } } When actionPerformed is called, the top element of the stack corresponds to the actionPerformed method. When getAccount is called, information corresponding to getAccount is placed on top of the calling stack. When getAccount returns, the stack frame corresponding to getAccount is removed from the calling stack, and the information corresponding to actionPerformed is once again at the top of the calling stack. Most Java programmers are familiar with the depiction of a calling stack shown in Figur e 11- 3 . Figure 11-3. An exception stack trace Stack traces are one of the single most useful debugging tools around; theyre often very useful in tracking program flow even when an exception hasnt been thrown. The stack trace shown earlier was generated by adding new Throwable.printStackTrace ; to the bank Throwable.printStackTrace ; to the bank examples client application. This stack is important because it lets us attach information to the programs flow of execution. In particular, it is useful to think of the stack as containing the following information: The arguments to the method being called Primitive arguments are passed by value, and objects are passed by reference. This means that if you pass an integer into a method, and the method changes the value, the change isnt visible to the calling method. However, if you pass an object to a method, any changes to the object are visible to the calling method. Locally scoped variables with primitive types. When an int or float is declared within a method, that variable is accessible only while that particular method is on top of the stack. Furthermore, locally scoped variables are accessible by only one particular stack frame. If a method appears twice in the calling stack, there are two distinct and independent sets of local variables. Synchronization information. I havent explained this yet. And, technically speaking, this information isnt stored in the stack frames. But, nonetheless, it is often useful to associate synchronization information with the method with which it is acquired and eventually released.

11.2.2 The Heap