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ū)別涉及延遲，內存訪問氓癌，部分故障和并發(fā)等方面。延遲的差異是最明顯的欧聘，但在許多方面是最不重要的。關于內存訪問端盆、部分故障和并發(fā)性的差異常常被忽略怀骤，要解釋清楚這些差異要困難得多，而關于部分故障和并發(fā)性的差異使得在不做出不可接受的妥協(xié)的情況下焕妙，統(tǒng)一本地和遠程計算模型是不可能的蒋伦。

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.
本地對象調用與遠程（或可能是遠程）對象上的調用之間最明顯的區(qū)別與兩個調用的延遲有關。兩者之間的差異目前在4到5個數(shù)量級之間焚鹊，考慮到處理器速度和網(wǎng)絡延遲速度發(fā)生變化的相對速率痕届，未來的差異最多不會更好韧献，而且可能會更糟。正是這種效率差異經(jīng)常被視為本地和分布式計算之間的本質區(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.
忽略本地調用和遠程調用性能之間的差異會導致設計的實現(xiàn)幾乎肯定會出現(xià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.
然而申屹，早些時候概述的設想對這一反對意見有一個答復绘证。答案是雙管齊下。第一種方法是依賴底層硬件的穩(wěn)定增長速度哗讥，使延遲的差異變得無關緊要嚷那。人們常常認為，這就是從高級語言到虛擬內存杆煞，效率問題涉及到的所有問題（的解決方法）魏宽。在最前沿的設計總是要求硬件在設計對現(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.
第二種方法是承認需要一些工具瑞驱，這些工具將允許開發(fā)人員了解組成應用程序的對象之間的通信模式。一旦這些工具可用窄坦，就需要進行調優(yōu)唤反，將經(jīng)常接觸的對象存儲到相同的地址空間，同時將相對不經(jīng)常接觸的對象移動到最方便的地方鸭津。由于該設想允許所有對象使用相同的底層機制進行通信彤侍，因此只需更改相關對象的實現(xiàn)細節(jié)(如對象位置)就可以實現(xiàn)此類調優(yōu)。但是逆趋，首先要確保應用程序正確盏阶，然后才能考慮效率。

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.
是否有可能掩蓋本地對象調用和分布式對象調用之間的效率差異闻书，這并不需要事先回答蛾派。完全掩蓋這種區(qū)別不僅需要遠程對象調用底層技術的改進腋舌，而且還需要更改開發(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.
如果本地和分布式對象調用之間的唯一區(qū)別是調用所花費的時間的不同，那么將來這兩種調用在概念上是不可區(qū)分的萎津。分布式計算技術是否已經(jīng)發(fā)展到足以讓人們基于這種技術來規(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.
然而，這兩種調用之間的延遲差異只是最明顯的差異。實際上冀值，這種差異并不是兩種調用間的根本區(qū)別也物，即使有可能將分布式調用技術發(fā)展到兩種調用之間的延遲差異最小的程度，那么構建一個將兩個調用視為基本相似的編程范式也是不明智的列疗。事實上滑蚯，由于本地調用和遠程調用之間的延遲差異非常明顯，是兩者之間最常見的唯一差異作彤，所以往往掩蓋了更不可調和的差異膘魄。

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.
本地和遠程計算之間更基本（但仍然明顯）的區(qū)別在于兩種情況下的內存訪問 - 特別是在使用指針時。簡單地說竭讳，本地地址空間中的指針在另一個(遠程)地址空間中無效创葡。系統(tǒng)可以克服這種差異，但要使這種方法成功绢慢，必須要完全透明灿渴。存在兩種選擇:要么所有內存訪問必須由底層系統(tǒng)控制，要么程序員必須知道訪問的不同類型——本地訪問和遠程訪問胰舆。沒有中間選擇骚露。

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)一編程模型 ——使遠程訪問表現(xiàn)得像本地訪問一樣——那么底層機制必須完全控制所有內存訪問。提供分布式共享內存是完全免除程序員擔心遠程內存訪問（或本地和遠程之間的差異）的一種方法缚窿。最大限度地使用面向對象范式棘幸，并要求程序員構建一個“從頭到尾都是對象”的應用程序(也就是說，只有對象引用或值作為方法參數(shù)傳遞)倦零，是消除本地計算和遠程計算之間界限的另一種方法误续。下面的層可以通過編組和反編組方法參數(shù)以及用于地址內空間傳輸?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.
添加這樣一層來更換指向對象引用的指針扫茅，可以讓開發(fā)者進行對象交互時使用統(tǒng)一的接口——這是不可能實現(xiàn)的蹋嵌，除非讓開發(fā)者不再使用相對地址空間的指針。這種方法為想要開始編寫分布式應用程序的程序員設置了障礙葫隙，因為它要求那些程序員學習一種不使用地址空間相對指針的新編程風格栽烂。此外，在要求程序員學習這種語言時恋脚，就放棄了本地和分布式計算之間的完全透明性腺办。

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.
即使要提供一種不允許獲取指向對象的地址空間指針的語言(或者在請求此類指針時返回對象引用)，也需要提供一種對對象以外的實體進行跨地址空間引用的等效方法糟描。大多數(shù)程序員使用指針作為許多不同類型實體的引用菇晃。這些指針必須替換為可以在跨地址空間調用中使用的一些東西，否則程序員將需要知道這些調用(不允許指向這些實體的指針蚓挤，或者對這些指針做一些特殊的處理)和本地調用之間的區(qū)別磺送。同樣驻子，雖然這是可以做到的，但它確實違反了本地調用和遠程調用之間完全統(tǒng)一的原則估灿。由于內存訪問限制崇呵，這兩者必須有所不同。

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.”
危險在于宣揚“遠程訪問和本地訪問完全相同”的假說馅袁，而不是實施假說域慷。一種底層機制不能統(tǒng)一所有內存訪問，同時仍然提倡這種神話汗销，這既具有誤導性犹褒，又容易出錯。相信這個神話的程序員可能認為他們不需要改變他們的編程思維弛针。因此叠骑，程序員很可能在錯誤的上下文中使用指針，從而產(chǎn)生錯誤的結果削茁≈婕希“遠程就像本地一樣，”這樣的程序員認為茧跋，“所以我們只有一個統(tǒng)一的編程模型慰丛。”看起來瘾杭，程序員不需要改變他們的編程風格诅病。在底層機制的不完整實現(xiàn)中，或者允許實現(xiàn)語言直接訪問本地存儲器粥烁，系統(tǒng)不會處理所有內存訪問贤笆，那么必然會發(fā)生錯誤。之所以出現(xià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.
另一種方法是解釋本地訪問和遠程訪問之間的區(qū)別变勇，使程序員意識到遠程地址空間訪問與本地訪問是不一樣的。即使通過使用[1]中指定的接口定義語言并使其為分布式對象上的操作調用生成智能語言映射來消除一些痛苦贴唇，認識到這一差異的程序員就不會犯使用指針進行跨地址空間訪問的錯誤搀绣。程序員會知道它是錯誤的。通過不掩蓋這種差異戳气，程序員能夠學習何時使用一種訪問方法链患，何時使用另一種訪問方法。

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.
與延遲一樣瓶您，從邏輯上講麻捻，本地內存訪問和遠程內存訪問之間的差異可能被完全掩蓋纲仍，并將兩者的單一模型呈現(xiàn)給程序員。然而贸毕，當我們引入分布式計算的部分故障和并發(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
雖然不太可能明棍，但至少在邏輯上可能會掩蓋本地計算和分布式計算之間的延遲和內存訪問的差異乡革。目前還不清楚是否可以用本地計算范式來生成分布式應用程序的方式來實現(xiàn)這種掩蓋，但是仍然可能允許將一些新的編程技術用于這兩種活動摊腋。但是沸版，對于故障和并發(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)都包含易受周期性故障影響的組件馒铃。在本地計算的情況下，這樣的故障要么是完全的痕惋，影響到應用程序中一起工作的所有實體区宇，要么是由某個中央資源分配器(如本地機器上的操作系統(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.
在分布式計算中不是這種情況值戳，其中一個組件（機器议谷，網(wǎng)絡鏈路）可能會發(fā)生故障而其他組件繼續(xù)運行。不僅分布式組件的故障是獨立的堕虹，而且沒有公共代理能夠確定哪些組件發(fā)生故障卧晓，并將該故障通知其他組件，也沒有可以檢查的全局狀態(tài)來準確確定發(fā)生了什么錯誤赴捞。在分布式系統(tǒng)中逼裆，網(wǎng)絡鏈路的故障與該鏈路另一側的處理器的故障無法區(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ā)異成庹或無法完成任務這些本地計算中可能會發(fā)生的故障胜宇。當在執(zhí)行對象調用期間機器崩潰或網(wǎng)絡鏈接斷開時，會導致目標對象簡單地消失而不是將控制權返回給調用者恢着，從而導致此類故障桐愉。分布式計算的一個核心問題是確保在發(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.
故障對于如何設計接口和接口中操作的語義有著很大的影響掰派。故障要求程序處理不確定性从诲。當本地組件發(fā)生故障時，可以知道導致故障的系統(tǒng)的狀態(tài)以及故障后系統(tǒng)的狀態(tài)靡羡。而在分布式系統(tǒ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.
要在故障面前保持健壯性磅废，需要在接口級別上進行一些表示。僅僅改進一個組件的實現(xiàn)是不夠的荆烈。連接組件的接口必須能夠在任何可能的情況下聲明失敗的原因拯勉，并且必須有接口能在發(fā)生故障且無法確定原因時重構合理狀態(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.
如果一個對象與其調用者在地址空間中是共存的憔购，則不會出現(xiàn)故障宫峦。一個函數(shù)可能不能正常完成，但它總是要完成的玫鸟。關于完成了多少計算导绷，沒有任何不確定性。部分完成只能在導致其他組件失敗的情況下發(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.
在分布式計算的情況下考慮故障可能性并不意味著單個對象模型不能用于分布式計算和本地計算妥曲。問題不是“你能使遠程方法調用看起來像本地方法調用嗎?”而是“使遠程方法調用與本地方法調用相同的代價是什么?”“如果要有一個統(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.
第一條路徑是將所有對象視為本地對象檐盟，并設計所有接口，就好像調用它們并由它們調用的對象是本地的一樣押桃。選擇這條路徑的結果是葵萎，當用于產(chǎn)生分布式系統(tǒng)時，所得到的模型在面對故障時本質上是不確定的唱凯，因此是脆弱的和非魯棒的羡忘。這條路徑基本上需要忽略分布式計算的額外故障模式。由于無法排除這些故障磕昼，采用該模型的代價是要求此類故障是未處理的和災難性的卷雕。

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.
另一條路徑是將所有接口設計為遠程接口。也就是說票从，語義和操作都被設計成在面對全部和部分故障時具有確定性漫雕。然而，這為那些從未打算遠程使用的對象引入了不必要的保證和語義纫骑。就像內存訪問方法試圖要求所有訪問都是通過系統(tǒng)定義的引用而不是指針一樣蝎亚，這種方法也必須依賴程序員使用系統(tǒng)的規(guī)則或改變實現(xiàn)語言九孩，以便在所有對象調用上強制處理所有分布式不確定性形式先馆。

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)一模型的方法使本地計算與分布式計算一樣復雜梅惯。這樣的模型不但不會鼓勵分布式應用程序的產(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ā)性。分布式對象本質上必須處理并發(fā)方法調用脚作。如果堅持使用統(tǒng)一的編程模型葫哗，同樣的二分法也適用。要么所有對象都必須承擔并發(fā)語義的重要性球涛，要么所有對象都忽略該問題并在分布式時抱最好的希望劣针。同樣，這是接口問題亿扁，而不僅僅是實現(xiàn)問題捺典，因為處理并發(fā)只能通過接口的代理將信息從一個對象傳遞到另一個對象。因此从祝，要么整個編程模型必須忽略重要的故障模式襟己，從而導致脆弱的系統(tǒng);或者，整個編程模型必須為程序中的所有對象假定最壞情況下的復雜性模型牍陌，這使得任何程序的生產(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.
有人可能會說退客，多線程應用程序需要處理這些相同的問題。然而链嘀，它們間有一個細微的區(qū)別萌狂。在多線程應用程序中，操作調用的不確定性沒有真正的來源怀泊。應用程序程序員在需要時可以完全控制調用順序茫藏。分布式系統(tǒng)本質上引入了真正的異步操作調用。此外霹琼，非分布式系統(tǒng)务傲，即使是多線程的，也位于單個操作系統(tǒng)之上枣申，該操作系統(tǒng)可以幫助對象之間的通信售葡，并可以用于確定和幫助同步和故障恢復。另一方面忠藤，分布式系統(tǒng)沒有單一的資源分配挟伙、同步或故障恢復點，因此在概念上非常不同模孩。