Windows 2003 SP2 的线程饥饿
令我们惊讶的是，我们最近发现了这个 。 通过 Windows 2003 SP1，Microsoft 改变了关键部分的行为方式。 早期想要访问它们的线程是以 FIFO 方式提供服务的。 现在它们以纯粹的“随机”方式提供。
在我们的例子中，我们有这样的情况：
// I now it's kind of ugly design but works
void Class:RunInThread()
{
while(m_Running)
{
EnterCriticalSection(&m_CS);
DoSomeStuffWithList();
LeaveCriticalSection(&m_CS);
}
}
void Class::AddToList()
{
EnterCriticalSection(&m_CS);
AddSomeStuffToList();
LeaveCriticalSection(&m_CS);
}
因此，随着 2003 SP2 中关键部分的新实现，AddToList 可能会死于饥饿，因为无法保证它会被唤醒。
这个例子有点极端，但另一方面，我有数百万行代码，这些代码是在假设对关键部分的访问是序列化的情况下编写的。
有没有办法关闭这个新的关键部分？
编辑：由于不可能恢复旧版本，我想只进行全局搜索和替换，将 {Enter,Leaver}CriticalSection 更改为类似 My{Enter,Leave}CriticalSection 的内容。 您是否知道应该如何实现它，使其表现得完全类似于 SP2 之前的版本？
To our great surprise we found recently this. With SP1 for Windows 2003 Microsoft changed a way critical sections behave. Earlier threads wanting to access them were served in FIFO manner. Right now they are served in pure "random" way.
In our case we had something like this:
// I now it's kind of ugly design but works
void Class:RunInThread()
{
while(m_Running)
{
EnterCriticalSection(&m_CS);
DoSomeStuffWithList();
LeaveCriticalSection(&m_CS);
}
}
void Class::AddToList()
{
EnterCriticalSection(&m_CS);
AddSomeStuffToList();
LeaveCriticalSection(&m_CS);
}
So with new implementation of critical section in 2003 SP2 AddToList might die in starvation since there is no guarantie that it will be awaken.
This example is a little bit extreme but on the other hand I have millions lines of code that were written with assumption that access to critical sections is serialized.
Is there a way to turn off this new critical section?
EDIT: Since getting back old version is not possible I am thinking of just doing global Search&Replace to change {Enter,Leaver}CriticalSection into something like My{Enter,Leave}CriticalSection. Have you ideas how this should be implemented so it behaves exactly like pre-SP2 version ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不幸的是，你有一个问题。 您所做的是根据实现细节而不是规范来编写代码。
EnterCriticalSection 一直被记录为不保证线程获取该部分的任何特定顺序，但事实上，在旧版本的操作系统中，它们以 FIFO 方式执行此操作，这就是您的代码的基础。
关闭这种新行为方式的方法不是安装 SP1。
现在，话虽如此，我不相信您的代码会有不利的问题，除非您对线程的优先级有很大不同。 当然，这两种方法之一可能会连续多次获取该部分，即使另一种方法也在等待，但这应该不是问题。
Unfortunately, you have a problem. What you have done is write your code depending on an implementation detail, and not to the spec.
EnterCriticalSection has always been documented to not guarantee any particular order that threads will acquire the section, but the fact that they did do so in a FIFO-manner, in older versions of the operating system, is what you have based your code around.
The way to turn off this new way of behavior is not to install SP1.
Now, having said that, I don't believe that there will be adverse problems with your code, unless you have prioritized your threads wildly different. Sure, one of the two methods might acquire the section more than once in a row, even though the other method is also waiting, but that shouldn't be a problem.
这是一个已知问题： http://www .bluebytesoftware.com/blog/PermaLink,guid,e40c2675-43a3-410f-8f85-616ef7b031aa.aspx 不幸的是，唯一的方法似乎是构建代码，使其在关键部分花费更少的时间。
That's a known problem: http://www.bluebytesoftware.com/blog/PermaLink,guid,e40c2675-43a3-410f-8f85-616ef7b031aa.aspx Unfortunately the only way appears to be is to structure code such that it spends less time in critical section.