$30.3 FROM PROCESSES TO OBJECTS 957 If we start from non-O-O concurrency work,we will find that it largely relies on the notion of process.A process is a program unit that acts like a special-purpose computer: it executes a certain algorithm,usually repeating it until some external event triggers termination.A typical example is the process that manages a printer,repeatedly executing "Wait until there is at least a job in the print queue" "Get the next print job and remove it from the queue" "Print the job" Various concurrency models differ in how processes are scheduled and synchronized,compete for shared hardware resources,and exchange information.In some concurrent programming languages,you directly describe a process;in others,such as Ada,you may also describe process types,which at run time are instantiated into processes,much as the classes of object-oriented software are instantiated into objects. Similarities The correspondence seems indeed clear.As we start exploring how to combine ideas from concurrent programming and object-oriented software construction,it seems natural to identify processes with objects,and process types with classes.Anyone who has studied concurrent computing and discovers O-O development,or the other way around,will be struck by the similarities between these two technologies: Both rely on autonomous,encapsulated modules:processes or process types;classes. Like processes and unlike the subroutines of sequential,non-O-O approaches, objects will,from each activation to the next,retain the values they contain. To build reasonable concurrent systems,it is indispensable in practice to enforce heavy restrictions on how modules can exchange information;otherwise things quickly get out ofhand.The O-O approach,as we have seen,places similarly severe restrictions on inter-module communication. The basic mechanism for such communication may loosely be described,in both cases,under the general label of"message passing". So it is not surprising that many people have had a"Eureka!"when first thinking, Milner-like,about making objects concurrent.The unification,it seems,should come easily. This first impression is unfortunately wrong:after the similarities,one soon stumbles into the discrepancies Active objects Building on the analogies just summarized,a number of proposals for concurrent O-O mechanisms(see the bibliographical notes)have introduced a notion of"active object". From:Doug Lea, An active object is an object that is also a process:it has its own program to execute.In a “Concurrent Pro- definition from a book on Java: gramming in Java", Addison-Wesley, Each object is a single,identifiable process-like entity (not ulike a Unix 1996. process)with state and behavior.§30.3 FROM PROCESSES TO OBJECTS 957 If we start from non-O-O concurrency work, we will find that it largely relies on the notion of process. A process is a program unit that acts like a special-purpose computer: it executes a certain algorithm, usually repeating it until some external event triggers termination. A typical example is the process that manages a printer, repeatedly executing “Wait until there is at least a job in the print queue” “Get the next print job and remove it from the queue” “Print the job” Various concurrency models differ in how processes are scheduled and synchronized, compete for shared hardware resources, and exchange information. In some concurrent programming languages, you directly describe a process; in others, such as Ada, you may also describe process types, which at run time are instantiated into processes, much as the classes of object-oriented software are instantiated into objects. Similarities The correspondence seems indeed clear. As we start exploring how to combine ideas from concurrent programming and object-oriented software construction, it seems natural to identify processes with objects, and process types with classes. Anyone who has studied concurrent computing and discovers O-O development, or the other way around, will be struck by the similarities between these two technologies: • Both rely on autonomous, encapsulated modules: processes or process types; classes. • Like processes and unlike the subroutines of sequential, non-O-O approaches, objects will, from each activation to the next, retain the values they contain. • To build reasonable concurrent systems, it is indispensable in practice to enforce heavy restrictions on how modules can exchange information; otherwise things quickly get out of hand. The O-O approach, as we have seen, places similarly severe restrictions on inter-module communication. • The basic mechanism for such communication may loosely be described, in both cases, under the general label of “message passing”. So it is not surprising that many people have had a “Eureka!” when first thinking, Milner-like, about making objects concurrent. The unification, it seems, should come easily. This first impression is unfortunately wrong: after the similarities, one soon stumbles into the discrepancies. Active objects Building on the analogies just summarized, a number of proposals for concurrent O-O mechanisms (see the bibliographical notes) have introduced a notion of “active object”. An active object is an object that is also a process: it has its own program to execute. In a definition from a book on Java: Each object is a single, identifiable process-like entity (not unlike a Unix process) with state and behavior. From: Doug Lea, “Concurrent Pro￾gramming in Java”, Addison-Wesley, 1996