?? models.html
字號:
<html><!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"><html> <head><title>Object Models for Concurrent and Distributed Java </title></head><BODY bgcolor=#ffffee vlink=#0000aa link=#cc0000><h1>Object Models for Concurrent and Distributed Java </h1>Even if you understand how to use Java concurrency mechanisms, it'shard to produce good designs without having good models of what's goingon in concurrent Java programs.<p>Contents:<ul> <li> <a href="#secMod"> Per-activity and Per-Object Concurrency</a>. <li> <a href="#secMix"> Mixtures </a>.</ul><h2><a name="secMod"></a>Per-Activity and Per-Object Concurrency Models</h2><p>There are two complementary ways to approach concurrency in Java:<dl> <dt> Per-activity concurrency model <dd> Programs implement designs in which a set of ``passive'' objects are created and have their methods activated due to the running of multiple threads, one per task that the program performs. <dt> Per-object concurrency model <dd> Programs implement designs in which a set of ``active'' objects, <em>EACH</em> with its own thread of control, interact.</dl><p>Each of these is described in more detail below.<p>While, at some level, these two models (as well as minor variants andcombinations) are equivalent, they have complementary strengths andweaknesses as approaches to designing Java programs:<ul> <li> The per-activity model meshes better with most aspects of Java <code>Thread</code> class usage. <li> The per-activity model meshes better with several common simple uses of threads in Applets; for example, starting a new thread to play an audio clip. <li> The per-object model meshes better with mechanics dealing with communication among two different Java processes (even, for example, firing up an Applet at a client). <li> The per-object model meshes better with large-scale OO system design. As discussed, for example in <A HREF="javascript:if(confirm('http://g.oswego.edu/dl/oosdw3/index.html \n\nThis file was not retrieved by Teleport Pro, because it is addressed on a domain or path outside the boundaries set for its Starting Address. \n\nDo you want to open it from the server?'))window.location='http://g.oswego.edu/dl/oosdw3/index.html'" tppabs="http://g.oswego.edu/dl/oosdw3/index.html">OOSD</A>, this view of objects is usually both easier and more productive for modeling real-world and design-level software objects than are ``passive'' object models. <li> The per-object model meshes better with the goal of building <em>reusable</em> components since it forces you to consider safety and consistency issues outside the context of particular tasks.</ul>In practice, you often need to shift points of view back and forthbetween these two ways of thinking about concurrency while developingJava programs. To a first approximation, per-activity-based designapplies most simply when new threads generate concurrent activitieswithin the same Java program but unrelated to those of any otherobject in the program, while per-object-based design applies mostsimply when programming distributed objects that connect overnetworks. However, nearly all OO systems employ all sorts of mixturesand in-between points in this spectrum.<h3>Common features</h3>Different object models make different assumptions about howobjects are structured, created, and used. But nearly allshare at least the following commonalities:<DL><DT> <STRONG>Encapsulation</STRONG><DD> Objects have ``membranes'' separating their `insides' and ``outsides''. Objects are described via a set of internal attribute representations, links (references) to other objects, states and local utility methods, along with interfaces describing methods or ``ports'' for accepting messages from other objects. When objects live in the same process, there is no ``physical'' enforcement of the distinction between the inside and outside of objects. However, the means for programmers to enforce this are common and standard -- use <CODE>private</CODE> (or sometimes <CODE>protected</CODE>) for instance variables and internal utility methods, and <CODE>public </CODE> for externally available methods.<DT> <STRONG>Instantiation</STRONG><DD> New objects of a certain form (normally as described by a <em>class</em>) can be constructed at any time (subject to system resource contraints).<DT> <STRONG>Message Passing</STRONG><DD> Objects communicate only via message passing; i.e., invoking a public (or otherwise accessible) method on another object. (For the sake of sanity, we ignore the fact that Java does have provisions for non-message-based communication via public instance variables.)</DL><h3>Per-activity concurrency</h3>Per-activity concurrency models mainly grew out of strategies fordeveloping software that could exploit multiple CPUs, lightweightprocesses, shared memory etc. These map in a straightforward fashionto many Java primitives. In a per-activity concurrency model, thereare two kinds of entities, ``passive'' objects and ``active'' threads.Passive objects have features including:<DL><DT> <STRONG>Objects as Data + Code</STRONG><DD> Each object is represented as a bundle of integrated data (instance variables) and code (method bodies). All passive objects are created and have methods invoked due to the running of one or more Threads that initiate sets of activities. <DT> <STRONG>Synchronization</STRONG><DD> To prevent interference among methods being invoked by different threads, each passive object can be ``locked'' via the <CODE>synchronized</CODE> keyword. (For purposes of concurrent programming, it would have been nice for this to be the default, or for a whole class to be declared as <CODE>synchronized</CODE>. But presumably because it is a bit expensive to implement synchronization, it must be specified explicitly. One nasty side effect of this language design decision is that classes that were originally written to be usable only sequentially cannot be used safely without modification in concurrent settings.) <DT> <STRONG>Message Passing</STRONG><DD> All message passing among passive objects follows a classic call/return procedural form (along with Exceptions, which are variants of procedural messages.)</DL>Threads are different kinds of entities all together, with featuresincluding:<DL><DT> <STRONG>Instantiation</STRONG><DD> Activities are set into motion by constructing a <code>Thread</code> object that encapsulates the run-time state of an activity, and then independently <code>starting</code> any kind of code on any kinds of passive objects (in Java, the code in the associated <code>run()</code> method).<DT> <STRONG>Message Passing</STRONG><DD> Message passing among threads (not the passive objects within the threads) is performed mainly by ``signalling''. (For example, in Java by posting <code>InterruptedException</code>.) Additionally, code within the passive objects running in threads may cause their current threads to stop, suspend and/or resume.</DL><h3>Per-Object concurrency</h3>Per-object concurrency models unify the notions of objects andactivities. These models mainly grew out of strategies for developing<em>distributed</em> object applications where different objects arestrewn across different computers.Active object modelsmap fairly easily into constructs in most distributed systems wheredifferent objects reside on different machines, and communicate viainterprocess message passing mechanisms (See, for example <AHREF="javascript:if(confirm('http://www.cs.wustl.edu/~schmidt/Active-Objects.ps.Z \n\nThis file was not retrieved by Teleport Pro, because it is addressed on a domain or path outside the boundaries set for its Starting Address. \n\nDo you want to open it from the server?'))window.location='http://www.cs.wustl.edu/~schmidt/Active-Objects.ps.Z'" tppabs="http://www.cs.wustl.edu/~schmidt/Active-Objects.ps.Z">Lavenderand Schmidt's Active Object pattern</A>).<p>The most straightforward activeobject model includes the following characteristics:<DL><DT> <STRONG>Objects as Processes</STRONG><DD> Each object is a single, identifiable process-like entity (not unlike a Unix process) with state and behavior.<DT> <STRONG>Guarded Actions</STRONG><DD> Because each object is a <EM>single</EM> process, it can be doing only one thing at a time. Thus, it cannot perform multiple concurrent method actions that interfere with each other. (Note however that a given <EM>service</EM> interface <A HREF="javascript:if(confirm('http://g.oswego.edu/dl/rp/roles.html \n\nThis file was not retrieved by Teleport Pro, because it is addressed on a domain or path outside the boundaries set for its Starting Address. \n\nDo you want to open it from the server?'))window.location='http://g.oswego.edu/dl/rp/roles.html'" tppabs="http://g.oswego.edu/dl/rp/roles.html">(role)</A> may support a ``multithreaded'' <A HREF="javascript:if(confirm('http://g.oswego.edu/dl/ProtocolCharts/PC.html \n\nThis file was not retrieved by Teleport Pro, because it is addressed on a domain or path outside the boundaries set for its Starting Address. \n\nDo you want to open it from the server?'))window.location='http://g.oswego.edu/dl/ProtocolCharts/PC.html'" tppabs="http://g.oswego.edu/dl/ProtocolCharts/PC.html"> protocol</A> entailing many active objects.) <p> Additionally, active objects may control which (if any) activities they are performing at any given time on the basis of their current state. They may postpone actions associated with a particular message because they are not currently in a state that logically permits any action. These capabilities are usually expressed via concurrency control constructs such as <EM>guards</EM>.<DT> <STRONG>Message Passing</STRONG><DD> Objects communicate only via message passing, of at least two forms: <OL> <LI> <STRONG>Synchronous</STRONG> (procedural): A client sends a message to a server, and then waits idly until it receives a reply (sometimes only a <CODE>void</CODE> synchronization reply). <LI> <STRONG>Asynchronous</STRONG> (oneway): A client object sends a message to a server object but does not expect or wait for a reply; instead it continues along asynchronously with respect to the server. Sometimes asynchronous messages are called <EM>events</EM>. A different and more common example of oneway communication in Java is to open up a socket to another Java-based process and ship it some data that it construes as a request of some sort. <P> Asynchronous messages are the basic mechanism for obtaining concurrency of different activities across different objects. In most active object models, asynchronous messages are viewed as more primitive and fundamental than synchronous ones. A procedural message can be constructed via a pair of asynchronous ones (a request and a reply), along with guards that cause the client to wait for the reply. </OL></DL>To map active objects to computers, you can consider a collection ofconcurrently executing objects as collection of machines, eachcontinuously performing:<ul> <li> Accept a message. This may or may not entail substeps including: <ul> <li> Receive message. <li> Decode message in some fashion. <li> Queue message. <li> Evaluate internal state in deciding whether to accept, delay, or ignore message. </ul> <li> Execute a method corresponding to an accepted message; performing some sequence of operations of any of three forms:?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -