Monday, January 11, 2010
Parallel Computer Architecture
Parallel computer architectures are now going to real applications! This fact is demonstrated by the large number of application areas covered in this book (see section on applications of parallel computer architectures). The applications range from image analysis to quantum mechanics and databases. Still, the use of parallel architectures poses serious problems and requires the development of new techniques and tools. This book is a collection of best papers presented at the first workshop on two major research activities at the Universitat Erlangen-N/imberg and Technische Universitat Munchen. At both universities, more than 100 resarchers are working in the field of multiprocessor systems and network configurations and methods and tools for parallel systems. Indeed, the German Science Foundation (Deutsche Forschungsgemeinschaft ) has been sponsoring the projects under grant numbers SFB 182 and SFB 342. Research grants in the form of a Sonderforschungsbereich are given to selected German Universities in portions of three years following a thoroughful reviewing process. The overall duration of such a research grant is restricted to 12 years. The initiative at Erlangen-Nurnberg was started in 1987 and has been headed since this time by Prof. Dr. H. Wedekind. Work at TU-Miinchen began in 1990, head of this initiative is Prof. Dr A. Bode. The authors of this book are grateful to the Deutsche Forschungsgemeinsehaft for its continuing support in the field of research on parallel processing. The first section of the book is devoted to hardware apects of parallel systems. Here, a number of basic problems have to be solved. Latency and bandwidths of interconnection networks are a bottleneck for parallel process communicatlon. Optoelectronic media, discussed in this section, could change this fact. The sealabillty of parallel hardware is demonstrated with the multiprocessor system MEMSY based on the concept of distributed shared memory. Scalable parallel systems need fault tolerance mechanisms to garantee reliable system behaviour even in the presence of defects in parts of the system. An approach to fault tolerance for scalable parallel systems is discussed in this section. The next section is devoted to performance aspects of parallel systems. Analytical models for performance prediction are presented as well as a new hardware monitor system together with the evaluation software. Tools for the automatic parallelization of existing applications are a dream, but not yet reality for the user of parallel systems. Different aspects for automatic treatment of parallel apphcations are covered in the next section on architectures and tools for paral]elizatlon. Dynamic lead balancing is an application transparent mechanism of the operating system to guarantee equal lead on the elements of a multiprocessor system. Randomizod shared memory is one possible implementation of a virtual shared memory based on distributed memory hardware.
Interface ActionListener
Interface ActionListener.
public interface ActionListener
The ActionListener interface is an addition to the Portlet interface. If an object wishes to receive action events in the portlet, this interface has to be implemented additionally to the Portlet interface.
public interface ActionEvent
extends Event
An ActionEvent is sent by the portlet container when an HTTP request is received that is associated with an action.
static int ACTION_PERFORMED
Event identifier indicating that portlet request has been received that one or more actions associated with it.
PortletAction getAction()
Deprecated. Use getActionString() instead
java.lang.String getActionString()
Returns the action string that this action event carries.
ACTION_PERFORMED
public static final int ACTION_PERFORMED
Event identifier indicating that portlet request has been received that one or more actions associated with it. Each action will result in a separate event being fired.
An event with this id is fired when an action has to be performe
void actionPerformed(ActionEvent event)
Notifies this listener that the action which the listener is watching for has been performed
Method Detail
actionPerformed
public void actionPerformed(ActionEvent event)
throws PortletException
Notifies this listener that the action which the listener is watching for has been performed.
Parameters:
event - the action event
Throws:
PortletException - if the listener has trouble fulfilling the request
public interface ActionListener
The ActionListener interface is an addition to the Portlet interface. If an object wishes to receive action events in the portlet, this interface has to be implemented additionally to the Portlet interface.
public interface ActionEvent
extends Event
An ActionEvent is sent by the portlet container when an HTTP request is received that is associated with an action.
static int ACTION_PERFORMED
Event identifier indicating that portlet request has been received that one or more actions associated with it.
PortletAction getAction()
Deprecated. Use getActionString() instead
java.lang.String getActionString()
Returns the action string that this action event carries.
ACTION_PERFORMED
public static final int ACTION_PERFORMED
Event identifier indicating that portlet request has been received that one or more actions associated with it. Each action will result in a separate event being fired.
An event with this id is fired when an action has to be performe
void actionPerformed(ActionEvent event)
Notifies this listener that the action which the listener is watching for has been performed
Method Detail
actionPerformed
public void actionPerformed(ActionEvent event)
throws PortletException
Notifies this listener that the action which the listener is watching for has been performed.
Parameters:
event - the action event
Throws:
PortletException - if the listener has trouble fulfilling the request
INTRO OF Data representation &Immutability IN JAVA
Data representation changes in scientific applications. Simple example: represent a point using Cartesian or polar coordinates. Polynomials (coefficents vs. point-value), matrices (sparse vs. dense).
Immutability. An immutable data type is a data type such that the value of an object never changes once constructed. Examples: Complex and String. When you pass a String to a method, you don't have to worry about that method changing the sequence of characters in the String. On the other hand, when you pass an array to a method, the method is free to change the elements of the array.
Immutable data types have numerous advantages. they are easier to use, harder to misuse, easier to debug code that uses immutable types, easier to guarantee that the class variables remain in a consistent state (since they never change after construction), no need for copy constructor, are thread-safe, work well as keys in symbol table, don't need to be defensively copied when used as an instance variable in another class. Disadvantage: separate object for each value.
Josh Block, a Java API architect, advises that "Classes should be immutable unless there's a very good reason to make them mutable....If a class cannot be made immutable, you should still limit its mutability as much as possible."
Give example where function changes value of some Complex object, which leaves the invoking function with a variable whose value it cannot rely upon.
mutable immutable
------------------------------------
Counter Complex
MovingCharge Charge
Draw String
array Vector
java.util.Date primitive types
Picture wrapper types
Final. Java provides language support to enforce immutability. When you declare a variable to be final, you are promising to assign it a value only once, either in an initializer or in the constructor. It is a compile-time error to modify the value of a final variable. public class Complex {
private final double re;
private final double im;
public Complex(double real, double imag) {
re = real;
im = imag;
}
// compile-time error
public void plus(Complex b) {
re = this.re + b.re; // oops, overwrites invoking object's value
im = this.im + b.re; // compile-time error since re and im are final
return new Complex(re, im);
}
}
It is good style to use the modifier final with instance variables whose values never change.
Serves as documentation that the value does not change.
Prevents accidental changes.
Makes programs easier to debug, since it's easier to keep track of the state: initialized at construction time and never changes.
Mutable instance variables. If the value of a final instance variable is mutable, the value of that instance variable (the reference to an object) will never change - it will always refer to the same object. However, the value of the object itself can change. For example, in Java, arrays are mutable objects: if you have an final instance variable that is an array, you can't change the array (e.g., to change its length), but you can change the individual array elements.
This creates a potential mutable hole in an otherwise immutable data type. For example, the following implementation of a Vector is mutable. public final class Vector {
private final int N;
private final double[] coords;
public Vector(double[] a) {
N = a.length;
coords = a;
}
...
}
A client program can create a Vector by specifying the entries in an array, and then change the elements of the Vector from (3, 4) to (0, 4) after construction (thereby bypassing the public API). double[] a = { 3.0, 4.0 };
Vector vector = new Vector(a);
StdOut.println(vector.magnitude()); // 5.0
a[0] = 0.0; // bypassing the public API
StdOut.println(vector.magnitude()); // 4.0
Defensive copy. To guarantee immutability of a data type that includes an instance variable of a mutable type, we perform a defensive copy. By creating a local copy of the array, we ensure that any change the client makes to the original array has no effect on the object. public final class Vector {
private final int N;
private final double[] coords;
public Vector(double[] a) {
N = a.length;
// defensive copy
coords = new double[N];
for (int i = 0; i < N; i++) {
coords[i] = a[i];
}
}
...
}
Program Vector.java encapsulates an immutable array.
Global constants. The final modifier is also widely used to specify local or global constants. For example, the following appears in Java's Math library. public static final double E = 2.7182818284590452354;
public static final double PI = 3.14159265358979323846;
If the variables were declared public, a client could wreak havoc by re-assigning Math.PI = 1.0; Since Math.PI is declared to be private, such an attempt would be flagged as a compile-time error.
Immutability. An immutable data type is a data type such that the value of an object never changes once constructed. Examples: Complex and String. When you pass a String to a method, you don't have to worry about that method changing the sequence of characters in the String. On the other hand, when you pass an array to a method, the method is free to change the elements of the array.
Immutable data types have numerous advantages. they are easier to use, harder to misuse, easier to debug code that uses immutable types, easier to guarantee that the class variables remain in a consistent state (since they never change after construction), no need for copy constructor, are thread-safe, work well as keys in symbol table, don't need to be defensively copied when used as an instance variable in another class. Disadvantage: separate object for each value.
Josh Block, a Java API architect, advises that "Classes should be immutable unless there's a very good reason to make them mutable....If a class cannot be made immutable, you should still limit its mutability as much as possible."
Give example where function changes value of some Complex object, which leaves the invoking function with a variable whose value it cannot rely upon.
mutable immutable
------------------------------------
Counter Complex
MovingCharge Charge
Draw String
array Vector
java.util.Date primitive types
Picture wrapper types
Final. Java provides language support to enforce immutability. When you declare a variable to be final, you are promising to assign it a value only once, either in an initializer or in the constructor. It is a compile-time error to modify the value of a final variable. public class Complex {
private final double re;
private final double im;
public Complex(double real, double imag) {
re = real;
im = imag;
}
// compile-time error
public void plus(Complex b) {
re = this.re + b.re; // oops, overwrites invoking object's value
im = this.im + b.re; // compile-time error since re and im are final
return new Complex(re, im);
}
}
It is good style to use the modifier final with instance variables whose values never change.
Serves as documentation that the value does not change.
Prevents accidental changes.
Makes programs easier to debug, since it's easier to keep track of the state: initialized at construction time and never changes.
Mutable instance variables. If the value of a final instance variable is mutable, the value of that instance variable (the reference to an object) will never change - it will always refer to the same object. However, the value of the object itself can change. For example, in Java, arrays are mutable objects: if you have an final instance variable that is an array, you can't change the array (e.g., to change its length), but you can change the individual array elements.
This creates a potential mutable hole in an otherwise immutable data type. For example, the following implementation of a Vector is mutable. public final class Vector {
private final int N;
private final double[] coords;
public Vector(double[] a) {
N = a.length;
coords = a;
}
...
}
A client program can create a Vector by specifying the entries in an array, and then change the elements of the Vector from (3, 4) to (0, 4) after construction (thereby bypassing the public API). double[] a = { 3.0, 4.0 };
Vector vector = new Vector(a);
StdOut.println(vector.magnitude()); // 5.0
a[0] = 0.0; // bypassing the public API
StdOut.println(vector.magnitude()); // 4.0
Defensive copy. To guarantee immutability of a data type that includes an instance variable of a mutable type, we perform a defensive copy. By creating a local copy of the array, we ensure that any change the client makes to the original array has no effect on the object. public final class Vector {
private final int N;
private final double[] coords;
public Vector(double[] a) {
N = a.length;
// defensive copy
coords = new double[N];
for (int i = 0; i < N; i++) {
coords[i] = a[i];
}
}
...
}
Program Vector.java encapsulates an immutable array.
Global constants. The final modifier is also widely used to specify local or global constants. For example, the following appears in Java's Math library. public static final double E = 2.7182818284590452354;
public static final double PI = 3.14159265358979323846;
If the variables were declared public, a client could wreak havoc by re-assigning Math.PI = 1.0; Since Math.PI is declared to be private, such an attempt would be flagged as a compile-time error.
defination of Encapsulation in Java ..Access control.,Getters and setters.
Encapsulation in Java. Java provides language support for information hiding. When we declare an instance variable (or method) as private, this means that the client (code written in another module) cannot directly access that instance variable (or method). The client can only access the API through the public methods and constructors. Programmer can modify the implementation of private methods (or use different instance variables) with the comfort that no client will be directly affected.
Program Counter.java implements a counter, e.g., for an electronic voting machine. It encapsulates a single integer to ensure that it can only get incremented by one at at time and to ensure that it never goes negative. The goal of data abstraction is to restrict which operations you can perform. Can ensure that data type value always remains in a consistent state. Can add logging capability to hit(), e.g., to print timestamp of each vote. In the 2000 presidential election, Al Gore received negative 16,022 votes on an electronic voting machine in Volusia County, Florida. The counter variable was not properly encapsulated in the voting machine software!
Access control. Java provides a mechanism for access control to prevent the use of some variable or method in one part of a program from direct access in another. We have been careful to define all of our instance variables with the private access modifier. This means that they cannot be directly accessed from another class, thereby encapsulating the data type. For this reason, we always use private as the access modifier for our instance variables and recommend that you do the same. If you use public then you will greatly limit any opportunity to modify the class over time. Client programs may rely on your public variable in thousands of places, and you will not be able to remove it without breaking dependent code.
Getters and setters. A data type should not have public instance variables. You should obey this rule not just in letter, but also in spirit. Novice programmers are often tempted to include get() and set() methods for each instance variable, to read and write its value.
Complex a = new Complex(1.0, 2.0);
Complex b = new Complex(3.0, 4.0);
// violates spirit of encapsulation
Complex c = new Complex(0.0, 0.0);
c.setRe(a.re() + b.re());
c.setIm(a.im() + b.im());
// better design
Complex a = new Complex(1.0, 2.0);
Complex b = new Complex(3.0, 4.0);
Complex c = a.plus(b);
The purpose of encapsulation is not just to hide the data, but to hide design decisions which are subject to change. In other words, the client should tell an object what to do, rather than asking an object about its state (get()), making a decision, and then telling it how to do it (set()). Usually it's better design to not have the get() and set() methods. When a get() method is warranted, try to avoid including a set() method
Program Counter.java implements a counter, e.g., for an electronic voting machine. It encapsulates a single integer to ensure that it can only get incremented by one at at time and to ensure that it never goes negative. The goal of data abstraction is to restrict which operations you can perform. Can ensure that data type value always remains in a consistent state. Can add logging capability to hit(), e.g., to print timestamp of each vote. In the 2000 presidential election, Al Gore received negative 16,022 votes on an electronic voting machine in Volusia County, Florida. The counter variable was not properly encapsulated in the voting machine software!
Access control. Java provides a mechanism for access control to prevent the use of some variable or method in one part of a program from direct access in another. We have been careful to define all of our instance variables with the private access modifier. This means that they cannot be directly accessed from another class, thereby encapsulating the data type. For this reason, we always use private as the access modifier for our instance variables and recommend that you do the same. If you use public then you will greatly limit any opportunity to modify the class over time. Client programs may rely on your public variable in thousands of places, and you will not be able to remove it without breaking dependent code.
Getters and setters. A data type should not have public instance variables. You should obey this rule not just in letter, but also in spirit. Novice programmers are often tempted to include get() and set() methods for each instance variable, to read and write its value.
Complex a = new Complex(1.0, 2.0);
Complex b = new Complex(3.0, 4.0);
// violates spirit of encapsulation
Complex c = new Complex(0.0, 0.0);
c.setRe(a.re() + b.re());
c.setIm(a.im() + b.im());
// better design
Complex a = new Complex(1.0, 2.0);
Complex b = new Complex(3.0, 4.0);
Complex c = a.plus(b);
The purpose of encapsulation is not just to hide the data, but to hide design decisions which are subject to change. In other words, the client should tell an object what to do, rather than asking an object about its state (get()), making a decision, and then telling it how to do it (set()). Usually it's better design to not have the get() and set() methods. When a get() method is warranted, try to avoid including a set() method
Designing APIs
Designing APIs. Often the most important and most challenging step in building software is designing the APIs. In many ways, designing good programs is more challenging that writing the code itself. Takes practice, careful deliberation, and many iterations.
Specification problem. Document the API in English. Clearly articulate behavior for all possible inputs, including side effects. "Write to specification." Difficult problem. Many bugs introduced because programmer didn't correctly understand description of API. See booksite for information on automatic documentation using Javadoc.
Wide interfaces. "API should do one thing and do it well." "APIs should be as small as possible, but no smaller." "When in doubt, leave it out." (It's easy to add methods to an existing API, but you can never remove them without breaking existing clients.) APIs with lots of bloat are known as wide interfaces. Supply all necessary operations, but no more. Try to make methods orthogonal in functionality. No need for a method in Complex that adds three complex numbers since there is a method that adds two. The Math library includes methods for sin(), cos(), and tan(), but not sec().
Java libraries tend to have wide interfaces (some designed by pros, some by committee). Sometimes this seems to be the right thing, e.g., String. Although, sometimes you end up with poorly designed APIs that you have to live with forever.
Deprecated methods. Sometimes you end up with deprecated methods that are no longer fully supported, but you still need to keep them or break backward compatibility. Once Java included a method Character.isSpace(), programmers wrote programs that relied on its behavior. Later, they wanted to change the method to support additional Unicode whitespace characters. Can't change the behavior of isSpace() or that would break many programs. Instead, add a new method Character.isWhiteSpace() and "deprecate" the old method. The API is now more confusing than needed.
Almost all methods in java.util.Date are deprecated in favor of java.util.GregorianCalendar.
Backward compatibility. The need for backward compatibility shapes much of the way things are done today (from operating systems to programming languages to ...). [Insert a story.]
Standards. It is easy to understand why writing to an API is so important by considering other domains. Fax machines, radio, MPEG-4, MP3 files, PDF files, HTML, etc. Simpler to use a common standard. Lack of incompatibilities enables business opportunities that would otherwise be impossible. One of the challenges of writing software is making it portable so that it works on a variety of operating systems including Windows, OS X, and Linux. Java Virtual Machine enables portability of Java across platforms.
Specification problem. Document the API in English. Clearly articulate behavior for all possible inputs, including side effects. "Write to specification." Difficult problem. Many bugs introduced because programmer didn't correctly understand description of API. See booksite for information on automatic documentation using Javadoc.
Wide interfaces. "API should do one thing and do it well." "APIs should be as small as possible, but no smaller." "When in doubt, leave it out." (It's easy to add methods to an existing API, but you can never remove them without breaking existing clients.) APIs with lots of bloat are known as wide interfaces. Supply all necessary operations, but no more. Try to make methods orthogonal in functionality. No need for a method in Complex that adds three complex numbers since there is a method that adds two. The Math library includes methods for sin(), cos(), and tan(), but not sec().
Java libraries tend to have wide interfaces (some designed by pros, some by committee). Sometimes this seems to be the right thing, e.g., String. Although, sometimes you end up with poorly designed APIs that you have to live with forever.
Deprecated methods. Sometimes you end up with deprecated methods that are no longer fully supported, but you still need to keep them or break backward compatibility. Once Java included a method Character.isSpace(), programmers wrote programs that relied on its behavior. Later, they wanted to change the method to support additional Unicode whitespace characters. Can't change the behavior of isSpace() or that would break many programs. Instead, add a new method Character.isWhiteSpace() and "deprecate" the old method. The API is now more confusing than needed.
Almost all methods in java.util.Date are deprecated in favor of java.util.GregorianCalendar.
Backward compatibility. The need for backward compatibility shapes much of the way things are done today (from operating systems to programming languages to ...). [Insert a story.]
Standards. It is easy to understand why writing to an API is so important by considering other domains. Fax machines, radio, MPEG-4, MP3 files, PDF files, HTML, etc. Simpler to use a common standard. Lack of incompatibilities enables business opportunities that would otherwise be impossible. One of the challenges of writing software is making it portable so that it works on a variety of operating systems including Windows, OS X, and Linux. Java Virtual Machine enables portability of Java across platforms.
Subscribe to:
Posts (Atom)