以编程方式确定抢占前剩余的时间量

时间:2013-07-18 20:58:43

标签: windows multithreading preemption

我正在尝试实现一些自定义无锁结构。它的操作类似于堆栈,因此它具有take()free()方法,并对指针和底层数组进行操作。通常它使用乐观的并发。 free()向指针+ 1写入一个虚拟值,使指针递增,并将实际值写入新地址。 take()以旋转/睡眠样式读取指针的值,直到它不读取虚拟值,然后递减指针。在两个操作中,对指针的更改都是通过比较和交换完成的,如果失败,整个操作将再次启动。虚拟值的目的是确保一致性,因为在指针递增后可以抢占写操作。

这种情况让我想知道天气是否有可能通过somhow确定在调度程序为另一个线程抢占线程之前还剩多少时间来阻止在该关键位置的预存。我不担心硬件中断。我试图从我的阅读功能中消除可能的睡眠,这样我就可以依靠纯粹的旋转。

这是可能的吗? 还有其他方法来处理这种情况吗?

编辑:澄清这可能有什么用处,如果关键操作被中断,它实际上就像取出一个独占锁,所有其他线程必须先睡觉才能继续他们的操作

编辑:我并不认为这样解决它,我只是想看看它是否可能。该操作在很长时间内被中断的概率极不可能,如果确实发生了,如果所有其他操作都需要睡眠以便它可以完成,那就没关系了。

有些人认为这是不成熟的优化,但这只是我的宠物项目。无论如何 - 这并不排除研究和科学尝试改进技术。尽管计算机科学已经相当成熟,而我们今天使用的每项新技术只是40年前已知的一种实现方式,但我们不应该停止创造性地解决即使是最小的问题,例如试图制定一套合理的问题。操作原子对性能的影响太多了。

2 个答案:

答案 0 :(得分:0)

没有时间旅行就无法完成。你被塞满了。

答案 1 :(得分:0)

这些信息肯定存在于某个地方,但对你没用。

在“正常条件”下,您可以预计每秒会有超过12个DPC和超过1,000个中断。这些不尊重你的时间片,它们发生时会发生。这意味着,平均而言,您可以在一个时间片内预期15-16次中断。

此外,调度并不严格按量级进行。当前Windows版本下的调度程序通常让一个线程运行2个量子,但如果某些外部条件发生变化(例如,如果发出事件对象信号),则可能会在中间更改其意见。

就此而言,即使你知道你还有那么多纳秒的时间,无论你认为你知道什么都可能不是真的。