4 Local and Distributed Computing
The major differences between local and distributed computing concern the areas of latency, memory access, partial failure, and concurrency.1 The difference in latency is the most obvious, but in many ways is the least fundamental. The often overlooked differences concerning memory access, partial failure, and concurrency are far more difficult to explain away, and the differences concerning partial failure and concurrency make unifying the local and remote computing models impossible without making unacceptable compromises.
本地和分布式計算之間的主要區(qū)別涉及延遲，內(nèi)存訪問，部分故障和并發(fā)等方面。延遲的差異是最明顯的，但在許多方面是最不重要的。關(guān)于內(nèi)存訪問、部分故障和并發(fā)性的差異常常被忽略，要解釋清楚這些差異要困難得多，而關(guān)于部分故障和并發(fā)性的差異使得在不做出不可接受的妥協(xié)的情況下，統(tǒng)一本地和遠(yuǎn)程計算模型是不可能的。
4.1 Latency
The most obvious difference between a local object invocation and the invocation of an operation on a remote (or possibly remote) object has to do with the latency of the two calls. The difference between the two is currently between four and five orders of magnitude, and given the relative rates at which processor speed and network latency speeds are changing, the difference in the future promises to be at best no better, and will likely be worse. It is this disparity in efficiency that is often seen as the essential difference between local and distributed computing.
本地對象調(diào)用與遠(yuǎn)程（或可能是遠(yuǎn)程）對象上的調(diào)用之間最明顯的區(qū)別與兩個調(diào)用的延遲有關(guān)。兩者之間的差異目前在4到5個數(shù)量級之間，考慮到處理器速度和網(wǎng)絡(luò)延遲速度發(fā)生變化的相對速率，未來的差異最多不會更好，而且可能會更糟。正是這種效率差異經(jīng)常被視為本地和分布式計算之間的本質(zhì)區(qū)別。
Ignoring the difference between the performance of local and remote invocations can lead to designs whose implementations are virtually assured of having performance problems because the design requires a large amount of communication between components that are in different
address spaces and on different machines. Ignoring the difference in the time it takes to make a remote object invocation and the time it takes to make a local object invocation is to ignore one of the major design areas of an application. A properly designed application will require determining, by understanding the application being designed, what objects can be made remote and what objects must be clustered together.
忽略本地調(diào)用和遠(yuǎn)程調(diào)用性能之間的差異會導(dǎo)致設(shè)計的實現(xiàn)幾乎肯定會出現(xiàn)性能問題，因為設(shè)計需要位于不同地址空間和不同機(jī)器上的組件之間進(jìn)行大量通信。忽略進(jìn)行遠(yuǎn)程對象調(diào)用和進(jìn)行本地對象調(diào)用所花費的時間上的差異會忽略應(yīng)用程序的主要設(shè)計領(lǐng)域之一。正確設(shè)計的應(yīng)用程序需要通過了解正在設(shè)計的應(yīng)用程序來確定哪些對象可以遠(yuǎn)程創(chuàng)建，哪些對象必須聚集在一起。
The vision outlined earlier, however, has an answer to this objection. The answer is two-pronged. The first prong is to rely on the steadily increasing speed of the underlying hardware to make the difference in latency irrelevant. This, it is often argued, is what has happened to efficiency concerns having to do with everything from high level languages to virtual memory. Designing at the cutting edge has always required that the hardware catch up before the design is efficient enough for the real world. Arguments from efficiency seem to have gone out of style in software engineering, since in the past such concerns have always been answered by speed increases in the underlying hardware.
然而，早些時候概述的設(shè)想對這一反對意見有一個答復(fù)。答案是雙管齊下。第一種方法是依賴底層硬件的穩(wěn)定增長速度，使延遲的差異變得無關(guān)緊要。人們常常認(rèn)為，這就是從高級語言到虛擬內(nèi)存，效率問題涉及到的所有問題（的解決方法）。在最前沿的設(shè)計總是要求硬件在設(shè)計對現(xiàn)實世界足夠有效之前趕上來。效率的爭論似乎在軟件工程中已經(jīng)過時了，因為在過去，這些問題總是通過底層硬件的速度提升來解決。
The second prong of the reply is to admit to the need for tools that will allow one to see what the pattern of communication is between the objects that make up an application. Once such tools are available, it will be a matter of tuning to bring objects that are in constant contact to the same address space, while moving those that are in relatively infrequent contact to wherever is most convenient. Since the vision allows all objects to communicate using the same underlying mechanism, such tuning will be possible by simply altering the implementation details (such as object location) of the relevant objects. However, it is important to get the application correct first, and after that one can worry about efficiency.
第二種方法是承認(rèn)需要一些工具，這些工具將允許開發(fā)人員了解組成應(yīng)用程序的對象之間的通信模式。一旦這些工具可用，就需要進(jìn)行調(diào)優(yōu)，將經(jīng)常接觸的對象存儲到相同的地址空間，同時將相對不經(jīng)常接觸的對象移動到最方便的地方。由于該設(shè)想允許所有對象使用相同的底層機(jī)制進(jìn)行通信，因此只需更改相關(guān)對象的實現(xiàn)細(xì)節(jié)(如對象位置)就可以實現(xiàn)此類調(diào)優(yōu)。但是，首先要確保應(yīng)用程序正確，然后才能考慮效率。
Whether or not it will ever become possible to mask the efficiency difference between a local object invocation and a distributed object invocation is not answerable a priori. Fully masking the distinction would require not only advances in the technology underlying remote object invocation, but would also require changes to the general programming model used by developers.
是否有可能掩蓋本地對象調(diào)用和分布式對象調(diào)用之間的效率差異，這并不需要事先回答。完全掩蓋這種區(qū)別不僅需要遠(yuǎn)程對象調(diào)用底層技術(shù)的改進(jìn)，而且還需要更改開發(fā)人員使用的通用編程模型。
If the only difference between local and distributed object invocations was the difference in the amount of time it took to make the call, one could strive for a future in which the two kinds of calls would be conceptually indistinguishable. Whether the technology of distributed computing has moved far enough along to allow one to plan products based on such technology would be a matter of judgement, and rational people could disagree as to the wisdom of such an approach.
如果本地和分布式對象調(diào)用之間的唯一區(qū)別是調(diào)用所花費的時間的不同，那么將來這兩種調(diào)用在概念上是不可區(qū)分的。分布式計算技術(shù)是否已經(jīng)發(fā)展到足以讓人們基于這種技術(shù)來規(guī)劃產(chǎn)品，這是一個判斷問題，理性的人可能不同意這種方法的智慧。
However, the difference in latency between the two kinds of calls is only the most obvious difference. Indeed, this difference is not really the fundamental difference between the two kinds of calls, and that even if it were possible to develop the technology of distributed calls to an extent that the difference in latency between the two sorts of calls was minimal, it would be unwise to construct a programming paradigm that treated the two calls as essentially similar. In fact, the difference in latency between local and remote calls, because it is so obvious, has been the only difference most see between the two, and has tended to mask the more irreconcilable differences.
然而，這兩種調(diào)用之間的延遲差異只是最明顯的差異。實際上，這種差異并不是兩種調(diào)用間的根本區(qū)別，即使有可能將分布式調(diào)用技術(shù)發(fā)展到兩種調(diào)用之間的延遲差異最小的程度，那么構(gòu)建一個將兩個調(diào)用視為基本相似的編程范式也是不明智的。事實上，由于本地調(diào)用和遠(yuǎn)程調(diào)用之間的延遲差異非常明顯，是兩者之間最常見的唯一差異，所以往往掩蓋了更不可調(diào)和的差異。
4.2 Memory Access
A more fundamental (but still obvious) difference between local and remote computing concerns the access to memory in the two cases—specifically in the use of pointers. Simply put, pointers in a local address space are not valid in another (remote) address space. The system can paper over this difference, but for such an approach to be successful, the transparency must be complete. Two choices exist: either all memory access must be controlled by the underlying system, or the programmer must be aware of the different types of access—local and remote. There is no inbetween.
本地和遠(yuǎn)程計算之間更基本（但仍然明顯）的區(qū)別在于兩種情況下的內(nèi)存訪問 - 特別是在使用指針時。簡單地說，本地地址空間中的指針在另一個(遠(yuǎn)程)地址空間中無效。系統(tǒng)可以克服這種差異，但要使這種方法成功，必須要完全透明。存在兩種選擇:要么所有內(nèi)存訪問必須由底層系統(tǒng)控制，要么程序員必須知道訪問的不同類型——本地訪問和遠(yuǎn)程訪問。沒有中間選擇。
If the desire is to completely unify the programming model—to make remote accesses behave as if they were in fact local—the underlying mechanism must totally control all memory access. Providing distributed shared memory is one way of completely relieving the programmer from worrying about remote memory access (or the difference between local and remote). Using the object-oriented paradigm to the fullest, and requiring the programmer to build an application with “objects all the way down,” (that is, only object references or values are passed as method arguments) is another way to eliminate the boundary between local and remote computing. The layer underneath can exploit this approach by marshalling and unmarshalling method arguments and return values for intra-address space transmission.
如果希望完全統(tǒng)一編程模型 ——使遠(yuǎn)程訪問表現(xiàn)得像本地訪問一樣——那么底層機(jī)制必須完全控制所有內(nèi)存訪問。提供分布式共享內(nèi)存是完全免除程序員擔(dān)心遠(yuǎn)程內(nèi)存訪問（或本地和遠(yuǎn)程之間的差異）的一種方法。最大限度地使用面向?qū)ο蠓妒?，并要求程序員構(gòu)建一個“從頭到尾都是對象”的應(yīng)用程序(也就是說，只有對象引用或值作為方法參數(shù)傳遞)，是消除本地計算和遠(yuǎn)程計算之間界限的另一種方法。下面的層可以通過編組和反編組方法參數(shù)以及用于地址內(nèi)空間傳輸?shù)姆祷刂祦砝眠@種方法。
But adding a layer that allows the replacement of all pointers to objects with object references only permits the developer to adopt a unified model of object interaction. Such a unified model cannot be enforced unless one also removes the ability to get address-space-relative pointers from the language used by the developer. Such an approach erects a barrier to programmers who want to start writing distributed applications, in that it requires that those programmers learn a new style of programming which does not use address-space-relative pointers. In requiring that programmers learn such a language, moreover, one gives up the complete transparency between local and distributed computing.
添加這樣一層來更換指向?qū)ο笠玫闹羔槪梢宰岄_發(fā)者進(jìn)行對象交互時使用統(tǒng)一的接口——這是不可能實現(xiàn)的，除非讓開發(fā)者不再使用相對地址空間的指針。這種方法為想要開始編寫分布式應(yīng)用程序的程序員設(shè)置了障礙，因為它要求那些程序員學(xué)習(xí)一種不使用地址空間相對指針的新編程風(fēng)格。此外，在要求程序員學(xué)習(xí)這種語言時，就放棄了本地和分布式計算之間的完全透明性。
Even if one were to provide a language that did not allow obtaining address-space-relative pointers to objects (or returned an object reference whenever such a pointer was requested), one would need to provide an equivalent way of making cross-address space reference to entities other than objects. Most programmers use pointers as references for many different kinds of entities. These pointers must either be replaced with something that can be used in cross-address space calls or the programmer will need to be aware of the difference between such calls (which will either not allow pointers to such entities, or do something special with those pointers) and local calls. Again, while this could be done, it does violate the doctrine of complete unity between local and remote calls. Because of memory access constraints, the two have to differ.
即使要提供一種不允許獲取指向?qū)ο蟮牡刂房臻g指針的語言(或者在請求此類指針時返回對象引用)，也需要提供一種對對象以外的實體進(jìn)行跨地址空間引用的等效方法。大多數(shù)程序員使用指針作為許多不同類型實體的引用。這些指針必須替換為可以在跨地址空間調(diào)用中使用的一些東西，否則程序員將需要知道這些調(diào)用(不允許指向這些實體的指針，或者對這些指針做一些特殊的處理)和本地調(diào)用之間的區(qū)別。同樣，雖然這是可以做到的，但它確實違反了本地調(diào)用和遠(yuǎn)程調(diào)用之間完全統(tǒng)一的原則。由于內(nèi)存訪問限制，這兩者必須有所不同。
The danger lies in promoting the myth that “remote access and local access are exactly the same” and not enforcing the myth. An underlying mechanism that does not unify all memory accesses while still promoting this myth is both misleading and prone to error. Programmers buying into the myth may believe that they do not have to change the way they think about programming. The programmer is therefore quite likely to make the mistake of using a pointer in the wrong context, producing incorrect results. “Remote is just like local,” such programmers think, “so we have just one unified programming model.” Seemingly, programmers need not change their style of programming. In an incomplete implementation of the underlying mechanism, or one that allows an implementation language that in turn allows direct access to local memory, the system does not take care of all memory accesses, and errors are bound to occur. These errors occur because the programmer is not aware of the difference between local and remote access and what is actually happening “under the covers.”
危險在于宣揚“遠(yuǎn)程訪問和本地訪問完全相同”的假說，而不是實施假說。一種底層機(jī)制不能統(tǒng)一所有內(nèi)存訪問，同時仍然提倡這種神話，這既具有誤導(dǎo)性，又容易出錯。相信這個神話的程序員可能認(rèn)為他們不需要改變他們的編程思維。因此，程序員很可能在錯誤的上下文中使用指針，從而產(chǎn)生錯誤的結(jié)果。“遠(yuǎn)程就像本地一樣，”這樣的程序員認(rèn)為，“所以我們只有一個統(tǒng)一的編程模型?！笨雌饋?，程序員不需要改變他們的編程風(fēng)格。在底層機(jī)制的不完整實現(xiàn)中，或者允許實現(xiàn)語言直接訪問本地存儲器，系統(tǒng)不會處理所有內(nèi)存訪問，那么必然會發(fā)生錯誤。之所以出現(xiàn)這些錯誤，是因為程序員沒有意識到本地訪問和遠(yuǎn)程訪問之間的區(qū)別，以及“實際上發(fā)生了什么”。
The alternative is to explain the difference between local and remote access, making the programmer aware that remote address space access is very different from local access. Even if some of the pain is taken away by using an interface definition language like that specified in [1] and having it generate an intelligent language mapping for operation invocation on distributed objects, the programmer aware of the difference will not make the mistake of using pointers for cross-address space access. The programmer will know it is incorrect. By not masking the difference, the programmer is able to learn when to use one method of access and when to use the other.
另一種方法是解釋本地訪問和遠(yuǎn)程訪問之間的區(qū)別，使程序員意識到遠(yuǎn)程地址空間訪問與本地訪問是不一樣的。即使通過使用[1]中指定的接口定義語言并使其為分布式對象上的操作調(diào)用生成智能語言映射來消除一些痛苦，認(rèn)識到這一差異的程序員就不會犯使用指針進(jìn)行跨地址空間訪問的錯誤。程序員會知道它是錯誤的。通過不掩蓋這種差異，程序員能夠?qū)W習(xí)何時使用一種訪問方法，何時使用另一種訪問方法。
Just as with latency, it is logically possible that the difference between local and remote memory access could be completely papered over and a single model of both presented to the programmer. When we turn to the problems introduced to distributed computing by partial failure and concurrency, however, it is not clear that such a unification is even conceptually possible.
與延遲一樣，從邏輯上講，本地內(nèi)存訪問和遠(yuǎn)程內(nèi)存訪問之間的差異可能被完全掩蓋，并將兩者的單一模型呈現(xiàn)給程序員。然而，當(dāng)我們引入分布式計算的部分故障和并發(fā)性問題時，甚至不清楚這種統(tǒng)一在概念上是否可行。
4.3 Partial failure and concurrency
While unlikely, it is at least logically possible that the differences in latency and memory access between local computing and distributed computing could be masked. It is not clear that such a masking could be done in such a way that the local computing paradigm could be used to produce distributed applications, but it might still be possible to allow some new programming technique to be used for both activities. Such a masking does not even seem to be logically possible, however, in the case of partial failure and concurrency. These aspects appear to be different in kind in the case of distributed and local computing.2
雖然不太可能，但至少在邏輯上可能會掩蓋本地計算和分布式計算之間的延遲和內(nèi)存訪問的差異。目前還不清楚是否可以用本地計算范式來生成分布式應(yīng)用程序的方式來實現(xiàn)這種掩蓋，但是仍然可能允許將一些新的編程技術(shù)用于這兩種活動。但是，對于故障和并發(fā)問題，這種屏蔽甚至在邏輯上都不可能。在分布式和本地計算的情況下，這些方面似乎是不同的。
Partial failure is a central reality of distributed computing. Both the local and the distributed world contain components that are subject to periodic failure. In the case of local computing, such failures are either total, affecting all of the entities that are working together in an application, or detectable by some central resource allocator (such as the operating system on the local machine).
故障是分布式計算的一個核心現(xiàn)實。本地和分布式系統(tǒng)都包含易受周期性故障影響的組件。在本地計算的情況下，這樣的故障要么是完全的，影響到應(yīng)用程序中一起工作的所有實體，要么是由某個中央資源分配器(如本地機(jī)器上的操作系統(tǒng))檢測到的。
This is not the case in distributed computing, where one component (machine, network link) can fail while the others continue. Not only is the failure of the distributed components independent, but there is no common agent that is able to determine what component has failed and inform the other components of that failure, no global state that can be examined that allows determination of exactly what error has occurred. In a distributed system, the failure of a network link is indistinguishable from the failure of a processor on the other side of that link.
在分布式計算中不是這種情況，其中一個組件（機(jī)器，網(wǎng)絡(luò)鏈路）可能會發(fā)生故障而其他組件繼續(xù)運行。不僅分布式組件的故障是獨立的，而且沒有公共代理能夠確定哪些組件發(fā)生故障，并將該故障通知其他組件，也沒有可以檢查的全局狀態(tài)來準(zhǔn)確確定發(fā)生了什么錯誤。在分布式系統(tǒng)中，網(wǎng)絡(luò)鏈路的故障與該鏈路另一側(cè)的處理器的故障無法區(qū)分。
These sorts of failures are not the same as mere exception raising or the inability to complete a task, which can occur in the case of local computing. This type of failure is caused when a machine crashes during the execution of an object invocation or a network link goes down, occurrences that cause the target object to simply disappear rather than return control to the caller. A central problem in distributed computing is insuring that the state of the whole system is consistent after such a failure; this is a problem that simply does not occur in local computing.
這些類型的故障不同于僅僅引發(fā)異?；驘o法完成任務(wù)這些本地計算中可能會發(fā)生的故障。當(dāng)在執(zhí)行對象調(diào)用期間機(jī)器崩潰或網(wǎng)絡(luò)鏈接斷開時，會導(dǎo)致目標(biāo)對象簡單地消失而不是將控制權(quán)返回給調(diào)用者，從而導(dǎo)致此類故障。分布式計算的一個核心問題是確保在發(fā)生這種故障后整個系統(tǒng)的狀態(tài)是一致的;這是一個在本地計算中根本不會發(fā)生的問題。
The reality of partial failure has a profound effect on how one designs interfaces and on the semantics of the operations in an interface. Partial failure requires that programs deal with indeterminacy. When a local component fails, it is possible to know the state of the system that caused the failure and the state of the system after the failure. No such determination can be made in the case of a distributed system. Instead, the interfaces that are used for the communication must be designed in such a way that it is possible for the objects to react in a consistent way to possible partial failures.
故障對于如何設(shè)計接口和接口中操作的語義有著很大的影響。故障要求程序處理不確定性。當(dāng)本地組件發(fā)生故障時，可以知道導(dǎo)致故障的系統(tǒng)的狀態(tài)以及故障后系統(tǒng)的狀態(tài)。而在分布式系統(tǒng)中，不能做出這樣的決策。相反，用于通信的接口必須設(shè)計成對象能夠以一致的方式對可能的故障作出反應(yīng)的方式。
Being robust in the face of partial failure requires some expression at the interface level. Merely improving the implementation of one component is not sufficient. The interfaces that connect the components must be able to state whenever possible the cause of failure, and there must be interfaces that allow reconstruction of a reasonable state when failure occurs and the cause cannot be determined.
要在故障面前保持健壯性，需要在接口級別上進(jìn)行一些表示。僅僅改進(jìn)一個組件的實現(xiàn)是不夠的。連接組件的接口必須能夠在任何可能的情況下聲明失敗的原因，并且必須有接口能在發(fā)生故障且無法確定原因時重構(gòu)合理狀態(tài)。
If an object is coresident in an address space with its caller, partial failure is not possible. A function may not complete normally, but it always completes. There is no indeterminism about how much of the computation completed. Partial completion can occur only as a result of circumstances that will cause the other components to fail.
如果一個對象與其調(diào)用者在地址空間中是共存的，則不會出現(xiàn)故障。一個函數(shù)可能不能正常完成，但它總是要完成的。關(guān)于完成了多少計算，沒有任何不確定性。部分完成只能在導(dǎo)致其他組件失敗的情況下發(fā)生。
The addition of partial failure as a possibility in the case of distributed computing does not mean that a single object model cannot be used for both distributed computing and local computing. The question is not “can you make remote method invocation look like local method invocation?” but rather “what is the price of making remote method invocation identical to local method invocation?” One of two paths must be chosen if one is going to have a unified model.
在分布式計算的情況下考慮故障可能性并不意味著單個對象模型不能用于分布式計算和本地計算。問題不是“你能使遠(yuǎn)程方法調(diào)用看起來像本地方法調(diào)用嗎?”而是“使遠(yuǎn)程方法調(diào)用與本地方法調(diào)用相同的代價是什么?”“如果要有一個統(tǒng)一的模型，必須選擇兩條路徑中的一條。
The first path is to treat all objects as if they were local and design all interfaces as if the objects calling them, and being called by them, were local. The result of choosing this path is that the resulting model, when used to produce distributed systems, is essentially indeterministic in the face of partial failure and consequently fragile and nonrobust. This path essentially requires ignoring the extra failure modes of distributed computing. Since one can’t get rid of those failures, the price of adopting the model is to require that such failures are unhandled and catastrophic.
第一條路徑是將所有對象視為本地對象，并設(shè)計所有接口，就好像調(diào)用它們并由它們調(diào)用的對象是本地的一樣。選擇這條路徑的結(jié)果是，當(dāng)用于產(chǎn)生分布式系統(tǒng)時，所得到的模型在面對故障時本質(zhì)上是不確定的，因此是脆弱的和非魯棒的。這條路徑基本上需要忽略分布式計算的額外故障模式。由于無法排除這些故障，采用該模型的代價是要求此類故障是未處理的和災(zāi)難性的。
The other path is to design all interfaces as if they were remote. That is, the semantics and operations are all designed to be deterministic in the face of failure, both total and partial. However, this introduces unnecessary guarantees and semantics for objects that are never intended to be used remotely. Like the approach to memory access that attempts to require that all access is through system-defined references instead of pointers, this approach must also either rely on the discipline of the programmers using the system or change the implementation language so that all of the forms of distributed indeterminacy are forced to be dealt with on all object invocations.
另一條路徑是將所有接口設(shè)計為遠(yuǎn)程接口。也就是說，語義和操作都被設(shè)計成在面對全部和部分故障時具有確定性。然而，這為那些從未打算遠(yuǎn)程使用的對象引入了不必要的保證和語義。就像內(nèi)存訪問方法試圖要求所有訪問都是通過系統(tǒng)定義的引用而不是指針一樣，這種方法也必須依賴程序員使用系統(tǒng)的規(guī)則或改變實現(xiàn)語言，以便在所有對象調(diào)用上強(qiáng)制處理所有分布式不確定性形式。
This approach would also defeat the overall purpose of unifying the object models. The real reason for attempting such a unification is to make distributed computing more like local computing and thus make distributed computing easier. This second approach to unifying the models makes local computing as complex as distributed computing. Rather than encouraging the production of distributed applications, such a model will discourage its own adoption by making all object-based computing more difficult.
這種方法也違背了統(tǒng)一對象模型的總體目的。嘗試這種統(tǒng)一的真正原因是使分布式計算更像本地計算，從而使分布式計算更容易。第二種統(tǒng)一模型的方法使本地計算與分布式計算一樣復(fù)雜。這樣的模型不但不會鼓勵分布式應(yīng)用程序的產(chǎn)生，反而會使所有基于對象的計算更加困難，從而阻礙其自身的采用。
Similar arguments hold for concurrency. Distributed objects by their nature must handle concurrent method invocations. The same dichotomy applies if one insists on a unified programming model. Either all objects must bear the weight of concurrency semantics, or all objects must ignore the problem and hope for the best when distributed. Again, this is an interface issue and not solely an implementation issue, since dealing with concurrency can take place only by passing information from one object to another through the agency of the interface. So either the overall programming model must ignore significant modes of failure, resulting in a fragile system; or the overall programming model must assume a worst-case complexity model for all objects within a program, making the production of any program, distributed or not, more difficult.
類似的論點也適用于并發(fā)性。分布式對象本質(zhì)上必須處理并發(fā)方法調(diào)用。如果堅持使用統(tǒng)一的編程模型，同樣的二分法也適用。要么所有對象都必須承擔(dān)并發(fā)語義的重要性，要么所有對象都忽略該問題并在分布式時抱最好的希望。同樣，這是接口問題，而不僅僅是實現(xiàn)問題，因為處理并發(fā)只能通過接口的代理將信息從一個對象傳遞到另一個對象。因此，要么整個編程模型必須忽略重要的故障模式，從而導(dǎo)致脆弱的系統(tǒng);或者，整個編程模型必須為程序中的所有對象假定最壞情況下的復(fù)雜性模型，這使得任何程序的生產(chǎn)，無論是否分布式，都更加困難。
One might argue that a multi-threaded application needs to deal with these same issues. However, there is a subtle difference. In a multi-threaded application, there is no real source of indeterminacy of invocations of operations. The application programmer has complete control over invocation order when desired. A distributed system by its nature introduces truly asynchronous operation invocations. Further, a non-distributed system, even when multi-threaded, is layered on top of a single operating system that can aid the communication between objects and can be used to determine and aid in synchronization and in the recovery of failure. A distributed system, on the other hand, has no single point of resource allocation, synchronization, or failure recovery, and thus is conceptually very different.
有人可能會說，多線程應(yīng)用程序需要處理這些相同的問題。然而，它們間有一個細(xì)微的區(qū)別。在多線程應(yīng)用程序中，操作調(diào)用的不確定性沒有真正的來源。應(yīng)用程序程序員在需要時可以完全控制調(diào)用順序。分布式系統(tǒng)本質(zhì)上引入了真正的異步操作調(diào)用。此外，非分布式系統(tǒng)，即使是多線程的，也位于單個操作系統(tǒng)之上，該操作系統(tǒng)可以幫助對象之間的通信，并可以用于確定和幫助同步和故障恢復(fù)。另一方面，分布式系統(tǒng)沒有單一的資源分配、同步或故障恢復(fù)點，因此在概念上非常不同。
