Tcl中的线程并不真正用作C线程

Question

在Tclsh线程包中，创建的线程不与主线程共享变量和命名空间，这与线程的C实现完全不同。为什么在tcl线程设计中存在这种矛盾。或者我在代码中遗漏了什么？是否所有脚本语言都具有类似的线程设计？

以下是Tcl线程文档PDF，

的引用

  

螺纹::创建   。必须加载所有其他扩展名   明确地进入每个线程   需要使用它们

Answer 1

它不是contradiction。 它只是一个不同的模型。它有其优点和缺点。您已经知道的关键缺点：不共享脚本和变量（除非您采取特殊步骤）。关键优势在于Tcl实现没有大的全局锁定，这使得有效使用多核硬件变得更加容易，并且意味着在执行此操作时非常很少。将此与Python Global Interpreter Lock进行对比，这是必要的，因为Python使用类似C的全局共享状态模型。

在低级别，Tcl的线程与幕后的大量线程共享变量强烈隔离，因此可以避免锁定（包括在内存管理中很多时间，否则这将是一个关键瓶颈）。线程间通信基于Tcl的内置事件排队系统;当两个线程通信时，一个发送消息并（可选地）等待另一个响应，接收者将消息放在其内部事件队列中，直到它处于准备好处理它的状态。这确实会减慢线程间通信速度，但当他们不进行通信时速度会快得多。

Answer 2

它实际上类似于在C：消息传递中使用线程的一种方式。当然，您也可以在C中以其他方式使用线程。但是消息传递是完全避免死锁的一种方法，因为信号量/互斥量可以在消息队列周围完全管理，并且在代码中的任何其他地方都不需要它们

这实际上是Tcl在C级实现的。事实上它是这样做的原因：避免使用信号量（以防止用户形成自己的死锁）。

大多数其他脚本语言只是提供一个围绕pthreads的瘦包装，这样如果你不小心你就会陷入僵局。我记得早在21世纪初，C和大多数其他语言中的线程编程的一般建议是实现消息传递架构以避免死锁。

由于tcl通常认为在脚本级别公开的API应该是高级别的，因此线程实现是通过内置的消息传递体系结构实现的。当然，还有一个方便的事实是它也避免了必须使tcl解释器线程安全（因此在解释器源代码中引入了互斥体）。

使解释器线程安全并非易事。有些语言在运行线程应用程序时遇到了神秘的崩溃。有些语言用了十多年的时间来解决所有漏洞问题。 Tcl决定不去尝试。 tcl解释器足够小并且旋转速度非常快，因此解决方案是每个线程只运行一个解释器。