分布式计算和线程有多相似?我发现有两篇论文得出了截然相反的结论:
“多线程比网络更容易。线程化是多么容易,和网络代码很相似”
http://software.intel.com/file/14723
(这给我的印象是,它们是如此相似,以至于在封装之后,这两种方法可以用相同的代码来完成-但也许我错了。)
“分布式计算笔记”
http://research.sun.com/techrep/1994/abstract-29.html
(这是一个很强的区别)
我确信真相介于两者之间。中庸之道是什么?有没有什么技术可以统一这两种范式?或者这种尝试失败了,是因为网络和并发之间的根本差异?
发布于 2009-05-02 23:40:14
我从未发现它们非常相似。为了这篇文章的目的,让我将“节点”定义为在一台机器上运行的一个硬件线程。因此,一个四核机器是四个节点,就像一个由四个单处理器盒组成的集群一样。
每个节点通常都会运行一些处理,并且需要进行某种类型的跨节点通信。通常,这种通信的第一个实例是告诉节点要做什么。对于这种通信,我可以使用共享内存、信号量、共享文件、命名管道、套接字、远程过程调用、分布式COM等。但最容易使用的共享内存和信号量通常不能在网络上使用。共享文件可能是可用的,但性能通常很差。套接字往往是网络上最常见和最灵活的选择,而不是更复杂的机制。在这一点上,您必须处理网络架构的细节,包括延迟、带宽、数据包丢失、网络拓扑等。
如果从一个工作队列开始,同一台机器上的节点可以使用简单的共享内存来完成任务。你甚至可以不加锁地写上它,它将会无缝地工作。在网络上有节点的情况下,将队列放在哪里?如果您将其集中在一起,该计算机可能会遭受非常高的带宽成本。试着分发它,事情很快就会变得非常复杂。
我发现,一般来说,处理这种类型的并行架构的人倾向于选择令人尴尬的并行问题来解决。我想到了光线追踪。除了作业分发之外,不需要太多的跨节点通信。当然,类似的问题还有很多,但我发现,认为分布式计算本质上等同于线程化的说法有点不真诚。
现在,如果你要编写行为与分布式系统相同的线程,使用纯消息传递,并且不假设任何线程是“主”线程之类的,那么是的,它们将非常相似。但你所做的是假装你有一个分布式架构,并在线程中实现它。问题是,与真正的分布式计算相比,线程是一种简单得多的并行情况。您可以将这两个问题抽象为一个问题,但通过选择较难的版本并严格遵守它。而且,当所有节点都位于计算机的本地时,结果将不会像预期的那样好。你没有利用这种特殊情况。
发布于 2009-05-02 23:30:27
分布式计算是在多台不同的独立机器上完成的,通常会有专门的操作系统。这很难,因为机器的互联性要低得多,因此需要对整个数据集进行大量快速、随机访问的问题很难解决。
一般来说,您需要专门的库来处理分布式计算问题,这些问题找出如何将节点分配给问题并处理数据。
我真的想知道他们是否得出了不同的结论,因为他们试图解决每个平台上的错误问题。一些问题很好地附着在高度互联的机器上,并可以从真正强大的超级计算机中受益。其他问题可以在简单的分布式模型上处理。一般来说,超级计算机可以解决更广泛的问题,但更专业,更昂贵。
发布于 2009-05-02 23:35:35
区别似乎回到了线程共享状态,进程传递消息。
在选择一个之前,你需要决定如何在你的应用中维护状态。
共享状态很容易上手,所有的数据和变量都在那里。但是一旦进入死锁/争用条件,就很难修改/扩展。
消息传递(如Erlang)需要一种不同的设计方法,你必须从一开始就考虑并发的机会,但每个分布式进程的状态是独立的,这使得锁定/竞争问题更容易处理。
https://stackoverflow.com/questions/815883
复制相似问题