什么机制阻止 System Verilog 线程同时获取信号量？
我很有可能误解了某些东西。由于 System Verilog 是一种事件驱动的并行语言（就验证而言），因此我很难理解底层架构。主要我想知道是什么阻止两个线程在同一时刻获取相同的信号量，这样每个线程都不会“意识到”另一个线程已经获取了它。对于像 C 这样的语言，我可以理解（例如在 RTOS 中）每个线程轮流与 CPU 一起模拟并行功能，尽管本质上是顺序的。 System Verilog 也是如此吗？
IEEE 标准是使用该语言的重要资源，但在理解硬件和软件之间的桥梁时（我的意思是使用该语言作为软件进行验证时）还有很多不足之处。
感谢您的时间和知识。
There is definitely a good chance I am misunderstanding something. Since System Verilog is an event driven parallel language (with respect to verification), I have trouble understanding the underlying architecture. Mainly I wonder what stops two threads from acquiring the same semaphore at the same instant such that each doesn't "realize" the other has already acquired it. For a language like C, I can understand that (in an RTOS for example) each thread takes turns with the CPU to emulate parallel functionality despite being sequential in nature. Is the same true for System Verilog?
The IEEE standard is a great resource for using the language, but leaves a lot to be desired when it comes to understanding the bridge between hardware and software (when using the language as software for verification I mean).
Thanks for your time and knowledge.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
RTOS 以及许多其他操作系统可以在多个内核上运行多个线程，因此所有线程不一定是顺序的。但与RTOS类似，SystemVerilog“时间”的概念是全局同步的资源，并且在所有线程之间共享。
因为 SystemVerilog 是一种硬件描述语言hdl，所以有大量的线程并行，使得多核执行成为一个非常困难的问题。即使在单个时间单位（事件区域）内也存在多个同步划分。尽管可以在一段时间内断开线程之间的同步（例如时钟周期或事务级别边界），但某些主线程内核必须在同步发生时进行协调。
IEEE 1800-2017 SystemVerilog LRM
不定义线程是顺序执行还是并发执行；仅保证或不保证订购的内容。 （4.6 决定论 和4.7 非决定论 节）。只是 SystemVerilog 线程的数量远多于每个并发运行的数量，并且调度语义是为 SystemVerilog 模拟内核以最佳方式编写的，以管理线程，就好像它们都是顺序的一样。
无论SystemVerilog线程是顺序执行还是并发执行，信号量请求的处理都是相同的。请求信号量密钥的线程向内核询问密钥，并且首先请求它的线程首先获取它。由于内核本身作为单线程运行，因此它可以确定谁应该以确定的方式获取密钥。
RTOS as well as many other OSs can run multiple threads on multiple cores, so all threads are not necessarily sequential. But similar an RTOS, the concept of SystemVerilog "time" is a globally synchronized resource and is shared among all threads.
Because SystemVerilog is a Hardware Description Language hdl, there is a massive amount of thread parallelism, making multi-core execution a very difficult problem. And there are also multiple divisions of synchronization even within a single time unit (event regions). Although it's possible to disconnect this synchronization between threads for a certain period of time, (like a clock cycle or transaction level boundary) some master thread kernel has to coordinate when that synchronization happens.
The IEEE 1800-2017 SystemVerilog LRM
does not define whether threads execute sequentially or concurrently; only what ordering is guaranteed or not. (Sections 4.6 Determinism and 4.7 Nondeterminism). It's just that there are far more SystemVerilog threads than could every run all concurrently, and the scheduling semantics are written most optimally for the SystemVerilog simulation kernel to manage the threads as if they were all sequential.
Regardless of whether SystemVerilog threads are executing sequentially or concurrently, the handling of semaphore is request is the same. The thread requesting the a semaphore key asks the kernel for the key, and the thread asking for it first—gets it first. Since the kernel is operating as a single thread itself, it gets to decide who should get the key in a deterministic way.