给定对象的核心模型是独立的计算引擎(存储是实例vars，CPU是类方法)响应从一个到另一个传递的消息，Smalltalk似乎很自然地适合在大量对象上进行并行处理。核心。然而，在这个领域，Smalltalk的确仍然非常薄弱，它对自己的模拟多任务功能做出了回应，这些功能没有利用现代处理器的硬件功能。
为什么是这样？主要问题是什么？可变性是关键，还是更特定于Smalltalk？
最佳答案
首先，让我们回想一下GemStone证明Smalltalk可以扩展为支持并行计算。当然，问题仍然存在，因为GemStone是一个非常复杂的系统(例如，在垃圾收集器中!)，而所有其他方言都不是那样。
并行计算需要线程安全代码；否则比赛条件将一直出现。问题在于，使Smalltalk代码具有线程安全性会在任何地方增加复杂性。考虑一下
OrderedCollection >> addLast: anObject
lastIndex = array size ifTrue: [self makeRoomAtLast].
lastIndex := lastIndex + 1.
^array at: lastIndex put: newObject
这些代码行之间的中断可能会使接收器的内部状态不一致。当然，非并行执行也会发生这种情况，因为Smalltalk支持中断。但是，Smalltalk使用此功能的方式仅限于不经常发生的关键部分，因此受到某种程度的控制。
在Smalltalk中添加线程安全代码不是那么自然的原因是在Smalltalk中我们有一个镜像。这意味着所有进程共享许多对象，包括所有类，编译方法等。Smalltalk的动态特性被系统及其应用程序广泛使用，这使事情变得更加困难。
以我的个人经验，在Smalltalk中实现多核功能的一种好方法是启动不同的OS进程( headless 图像实例)并使用Smalltalk信号和进程协调它们。在这种方法下，每个操作系统进程都由Smalltalk进程在主镜像(带有UI的镜像)中表示。主镜像和 headless 进程之间的通信可以依靠套接字(或任何其他功能)。当然，调试时要付出代价。实际上，最终您会跟踪日志文件中的许多事件，并在“ headless ”流程中打开调试器，直到您了解出了什么问题。但是，不仅可以作为演示，而且可以针对真正的“工业级”产品来完成。
关于multithreading - 使Smalltalk并行的困难是什么？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/35940570/