我有一个简单的确定性工作，只需要13条机器指令就可以完成。因为第一条指令使用一个自制的信号量（自旋锁），最后一条指令释放它，所以我可以安全地避开在其他内核上运行的所有其他线程，因为它们试图使用和给予相同的信号量。
当某个线程在持有信号量的线程能够完成其“临界段”之前中断该线程时，该问题出现。最坏的情况是，中断在持有信号量时杀死该线程，或者可能发生的是，通常竞争信号量的线程之一分支进入能够生成导致死锁的中断的代码。
当其他线程分支到我无法控制的代码部分时，我没有办法与它们同步。我想我需要禁用中断，就像我以前在VxWorks内核模式下运行时所做的那样。它总是有13条指令，如果我能在必须荣誉中断之前完成所有13条指令，我总是完全安全的。哦，这都是我自己的内部数据，除了自制的信号量没有什么可以锁定其他任何东西。
我读过几个答案，我认为答案很接近。大多数都与Windows API上的临界区调用有关（错误的操作系统，但可能是正确的概念）。大多数错误的解决方案都假设我可以让所有违规线程使用我用pthread库创建的互斥锁。
我需要在Linux和Solaris上用C/C++编写此解决方案。
约翰尼·克拉什的问题非常接近
KermitG还
感谢您的考虑。
2条答案
按热度按时间aurhwmvo1#
您可能无法防止用户模式线程的抢占。关键部分（和所有其他同步对象）可防止线程冲突，但它们绝不能防止操作系统抢占线程。
如果其他线程在超时时分支到 something，而该 something 可能导致死锁，则存在设计问题。
正确的设计应该是最悲观的：抢占可以在任何地方发生不确定时间。
nfzehxib2#
是的，是的- 7岁-我确实需要这样做，但出于其他原因。所以我把这个放在这里让别人在历史背景下阅读。
我正在为一个嵌入式RTOS编写一个仿真层，我需要在其中仿真嵌入式平台CPU_irq_disable（）和CPU_irq_restore（）。我能想到的最接近的方法是在调度程序中禁用抢占。
是的，目标有RTOS -有时没有。
IO通过套接字模拟，即：串行端口就像一个流套接字！
GPIO管脚（Edge IRQ）可以是一个套接字。当前值对于驱动器是准全局的，并且等待管脚更改=等待数据包到达套接字。
因此，当数据包出现时，套接字读取线程的行为就像IRQ一样。因此，为了模拟irq禁用，在我自己的应用程序中通过禁用抢占来模拟是合理的。
同样在嵌入式应用程序层，我需要模拟超循环。
再多的互斥体也无法合理地模拟嵌入式平台。