线程仅适用于断点设置 [英] Thread works well only with breakpoint(s) set

问题描述

你好，



感谢您抽出宝贵时间阅读这篇文章。我一直看到Visual Studio 2005多线程用户程序以高优先级运行时出现问题。



我正在研究无线网络协议，协议所做的一件事就是监控链路质量。我正在测试完美的链接，因此测量的链接质量应该是或接近100％。



此功能一直运行正常，直到我将代码更改为以更高的链接速率工作。以前的链接以千比特为单位;现在他们以每秒10和100的千比特为单位。



这是问题所在：



- 有时我发现线程监控链路质量无法一致地工作，因此当测量的链路质量接近完美时，测量的链路质量会下降。这发生在最后一个协议栈上启动。



- 当我使用Visual Studio 2005在线程中添加一个或多个断点时，它会在而。我可以说，断点最初会偶尔被击中，然后经常会被击中，并且测量的链路质量会上升到可接受的水平。禁用断点后，线程似乎继续工作正常，协议似乎应该工作，甚至一夜之间，直到我关闭它。



四元组 - 使用的oct-core PC具有较低的处理器利用率，并且有足够的主内存和磁盘空间。使用的操作系统是Windows 7和XP。上面的所有PC配置都出现了同样的问题，我没有尝试过任何其他配置。



如果有人可以提供帮助，我们将非常感激。



最好，

Jeremy



我尝试了什么：



起初我在同一台PC上运行了一些网络协议栈。我怀疑操作系统在支持如此多的高优先级进程时遇到了问题，因此我将一个堆栈移动到另一台PC。这工作了一段时间，但即使使用PC上的单个协议栈，问题也重新出现。

Hello,

Thanks for taking the time to read this post. I have been seeing a problem with a Visual Studio 2005 multithreaded user program running at high priority.

I am working on wireless network protocols and one thing the protocol does is monitor link quality. I am testing with perfect links so the link qualities measured should be at or near 100%.

This feature had been working okay till I changed the code to work at much higher link rates. The links used to go at kilobits per second; now they go at 10s and 100s of kilobits per second.

This is the problem:

- Sometimes I see that the thread monitoring link quality fails to work consistently so that the measured link quality goes down when it should be near perfect. This happens on the last protocol stack to start up.

- When I add one or more breakpoints in the thread using Visual Studio 2005, it starts working properly again after a while. I can tell as the breakpoints initially get hit once in a while, then very often, and the link quality measured goes up to acceptable levels. After I disable the breakpoints, the thread seems to keep working okay and the protocol appears to work as it should, even overnight, till I shut it down.

The quad- and oct-core PCs used have low processor utilization and there is ample main memory and disk space to spare. The operating systems used are Windows 7 and XP. All the PC configurations above have exhibited the same problem and I have not tried this on any other configuration.

It would be appreciated greatly if someone could help.

Best,
Jeremy

What I have tried:

At first I had a few network protocol stacks running on the same PC. I suspected the OS had problems supporting so many high priority processes, so I moved one stack to another PC. This worked for a while, but the problem has resurfaced even with the single protocol stack on a PC.

推荐答案

这很简单：如果你的线程只工作有了断点，它根本不起作用。代码很简单。该行为清楚地表明不正确依赖执行时间通常称为竞争条件：竞争条件 - 维基百科，免费的百科全书。



现在，因为你没有创建我们可以在这里考虑的任何代码示例，我无法分析它并找出你的代码设计错误的地方，或者它是否有某些错误。此外，它可能会发生很难找到竞争条件的确切原因，但通常会有一些间接的错误代码，一些技术甚至风格，可能正式导致正确的代码，但是不可饶恕且容易出错。



所以，我的建议是：正确学习线程技术并阅读我引用的文章，了解竞争条件如何让你陷入困境。欢迎您提出后续问题。

-SA

This is as simple as that: if your thread works only with the breakpoints, it does not work at all. The code is simple incorrect. The behavior is a clear indication of the phenomena of incorrect dependency on the time of execution commonly known as "race condition": Race condition — Wikipedia, the free encyclopedia.

Now, as you did not create any code sample we could consider here, I cannot analize it and find out where your code design is wrong, or if it has certain bugs. Also, it could so happen that it's too hard to find an exact reason for race condition, but usually there can be some indirect sings of wrong code, some techniques or even style which may formally result in correct code but are impractiable and error-prone.

So, my advice is: learn threading techniques properly and read the article I referenced to understand how race condition gets you into trouble. Your follow-up questions will be welcome.

—SA

这篇关于线程仅适用于断点设置的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！