C Erlang NIFs：线程锁定

NIF实现可以使用常规的C/C++线程锁定原语，还是必须使用NIF API（

enif\u mutex\u lock（..）、enif\u mutex\u create（..）、

等）

From

线程与并发 NIF是线程安全的，不需要任何显式同步，只要它作为纯函数并只读取提供的参数。一旦通过静态变量或enif_priv_数据写入共享状态，您就需要提供自己的显式同步。这包括线程之间共享的进程无关环境中的术语。如果您将资源对象视为可变的，则它们也需要同步

所以没有什么能阻止你做任何你想做的事。您可以很容易地编写自己的互斥/语义交换等等。你可以用C或C++或者生锈来做。

---

也就是说，没有什么可以阻止一切。如果你打碎了什么东西，你就把它整个打碎。我会尝试使用标准的Erlang方式来做事情，尤其是在使用线程进行分页时。这些都是经过验证的方法，我没有找到任何理由用其他方法替换它们

如果这对您有帮助的话，这就是

enif\u mutex\u lock（）

的实现方式：。看起来该线程被标记为被阻止。请尝试先编写一个端口，大多数情况下，您实际上不需要NIF。如果必须编写NIF（这应该是最后的选择），请使用NIFAPI。或者期望你的整个虚拟机因为你太聪明而变得不稳定。@zxq9来自官方文档：“NIF比使用端口驱动程序调用C代码更简单、更有效。”@GabiMe确实如此。但一旦你开始谈论互斥锁和锁之类的东西，你就完全失去了第二点的意义：“NIF最适合于同步函数，比如示例中的foo和bar，它可以进行一些相对较短的计算，而不会产生副作用并返回结果。”如果这种情况持续存在，您不需要担心锁定任何东西，而是需要使用端口。无聊的。。。不管怎样，这都是一次学习的经历。好吧，但是为什么Erlang首先要提供锁定API呢？使用C++代替常规锁有什么好处吗？同样的原因C++提供了列表和向量，所以你不会用潜在的错误重新实现它们。Erlangs锁/互斥锁中还有一些额外的调试信息。除此之外，还有正常工作的锁（因为不规则锁不起作用，也没有超级锁：）。除此之外，我同意@ ZXQ9的评论，如果你想知道你应该使用什么，使用端口，并考虑NIF的只有当你证明不够。