我通过在do_test1和do_test2的开头设置断点来调试Visual Studio 2008（64位）中的以下代码，令我惊讶的是，代码在{的同一个线程中运行{1}}功能。
我没有在Linux环境中调试。但是，通过搜索源代码，我发现某些SystemC库源代码包含sc_main。
问题1：在Windows中，"pthread.h"会创建一个真正的线程吗？或者它总是在SC_THREAD的同一个帖子中？如果是这种情况，我可以说sc_main正在创建一个“假”线程吗？
问题2：在Linux中，由于包含SC_THREAD，"pthread.h"会创建一个新线程吗？
问题3：在Windows和Linux中，我是否错过了启用真实线程的一些设置？
========================================
以下代码来自本网站：
http://www.asic-world.com/systemc/systemc_time4.html#Example_:_sc_event
SC_THREAD答案 0 :(得分：10)
简答：
线程库，无论是用户级线程（更轻和更快的上下文切换）还是内核级线程，都不用于提供真正的并发。相反，它们用于实现SC_THREAD进程的协同语义。
答案很长：
SystemC有3种类型的进程（即并发单元），其中最重要的只有两种：
SC_METHOD是方法（类似于Verilog中的always语句）
在由事件触发时，在整个 零时 执行。他们不能
使用wait等待时间间隔或事件发生。SC_THREAD是方法（如Verilog中的initial语句）
只执行一次，但他们可以使用wait等待特定的
事件或时间段，可以使用循环来模拟always
语句（因此SC_THREAD可以消耗时间）。对于实现透视图，SC_METHOD没有问题，因为它们就像在触发时要调用的SystemC内核中注册的方法一样。但是，对于SC_THREAD s，尽管它们被定义为成员函数，但它们的行为与普通例程不同。它们被称为coroutines：
子程序，允许多个入口点在某些位置暂停和恢复执行。
SystemC内核不为系统级或RTL模型提供真正的并发性。它仅通过流程构造提供模拟并发。因此，在编写高级模型时，您不必使用同步原语（例如，锁或信号量）来保护不同进程共享的数据，因为在任何时候，只有一个进程正在执行且不能被中止SystemC内核（执行切换到下一个进程，只有在当前正在执行的进程放弃控制时才能执行。仍然可以使用同步，但SystemC提升使用 消息传递 在 渠道 中进行流程之间的通信。这是一个优势，因为它降低了复杂性。但是，也有缺点.SystemC模型按顺序执行（不是并行化），因此它们不会利用多核架构来加速仿真。这是一个需要模拟性能的热门研究领域。
无论如何，SystemC内核因此实现 协作调度 ，其中每个SC_THREAD都愿意放弃控制（通过使用wait）来允许其他SC_THREAD {1}}要执行的进程。如果在SC_THREAD进程中有一个永不放弃控制的无限循环，那么整个模拟将停留在那里并且模拟时间不会提前。 SC_METHOD s也是如此，它必须返回SystemC内核才能重新获得控制权。
为了使用协同程序实现该协作调度策略，使用了一个线程库（例如，包含在SystemC源代码中的pthreads或QuickThread）来启用SC_THREAD（作为线程启动）暂停自己并使内核稍后恢复。请阅读this article以了解有关此内容的更多信息。
答案 1 :(得分：3)
否＆amp;是。这取决于您的SystemC库配置。
您可以将SystemC配置为使用pthread或Windows本机线程。因此，当您编译并运行SystemC设计时，它会创建REAL线程。但是，默认情况下，在UNIX环境中，默认情况下不会使用pthread，因为系统调用很昂贵。无论您如何配置SystemC以使用pthread或Window本机线程，SystemC只会逐个运行线程。因为它一次只运行一个线程，所以使用其用户级线程比其他线程更快，因为不涉及系统调用。
为什么SystemC不会立即运行所有计划线程？这是另一个问题。