使Smalltalk平行有什么困难？

Question

鉴于作为独立计算引擎的对象的核心模型(存储是实例变量,CPU是类方法)响应从一个传递到另一个的消息,似乎Smalltalk自然适合于大量的并行处理核心.然而,这是一个Smalltalk确实非常弱的领域,它回应了自己的模拟多任务功能,这些功能没有利用现代处理器的硬件功能.

为什么是这样？主要问题是什么？可变性是关键,还是Smalltalk更具体的东西？

Answer 1

首先,让我们回想一下,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中我们有一个图像.这意味着所有进程共享许多对象,包括例如所有类,编译方法等.Towtalk的动态特性(系统及其应用程序广泛使用)使事情变得更加困难.

根据我的个人经验,在Smalltalk中实现多核功能的一个好方法是启动不同的OS进程(无头图像的实例)并使用Smalltalk信号量和进程协调它们.在这种方法下,每个OS进程都通过Smalltalk进程在主图像(具有UI的图像)中表示.主图像和无头处理之间的通信可以依赖于套接字(或任何其他特征).当然,你在调试时要付出代价.实际上,您最终会在日志文件中跟踪大量事件并在"无头"进程中打开调试器,直到您了解出现了什么问题.但是可以做到,不仅仅是作为一个演示,而是一个真正的"工业强大"的产品.