.NET CF 2.0：可能的单线程重入
一个简单的应用程序是用 CF 2.0 编写的。 就我而言，它是单线程的。
该应用程序有两个部分值得关注：一个事件处理程序，用于处理由代表 PDA 条形码扫描仪（由制造商提供）的类引发的“条形码扫描”事件；以及一个每 30 秒运行一次的 Windows.Forms.Timer 事件处理程序。
最近，该应用程序遇到了一个错误，正如我所见，唯一可能的原因是在 Timer_Tick 事件中间处理条形码扫描事件。 我绝对确信这是不可能的，并且其中一个事件将在队列中等待，直到第一个事件完全处理为止。 MSDN 中的 Windows.Forms.Timer 页面还确保它是常规的单线程计时器。 由条形码扫描触发的代码会更改界面的某些部分，不会导致异常，因此我假设它也是单线程的。 不，我们没有使用 DoEvents 等。
任何人都可以肯定地告诉我，这种重入是不可能的，我应该更加努力地寻找其他可能的原因，反之亦然，他们也遇到了同样的问题？
A simple application is written in CF 2.0. It's single-threaded as far as I'm concerned.
Two parts of the application are of interest: an event handler that handles "Barcode scanned" event raised by a class that represents PDA's barcode scanner (provided by manufacturer), and an event handler for Windows.Forms.Timer that runs every 30 seconds.
Recently the application suffered from a bug the only possible reason for which, as I can see, is processing Barcode Scanned event right in the middle of Timer_Tick event. I was absolutely sure that this was not possible and that one of the events would wait in the queue until first one is handled completely. Windows.Forms.Timer page in MSDN also assures that it's a regular single-threaded timer. Code triggered by Barcode Scanned changes some pieces of the interface, that causes no exceptions, so I'm assuming it's single-threaded as well. No, we're not using DoEvents or such.
Can anybody tell me for sure that such reentrancy is not possible and I should look harder for other possible reasons, or vice versa, that they have suffered from the same problem?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Windows.Forms 计时器将通过调用 PostMessage 在 UI 线程上发生。 这是一个保证。 “条形码扫描”的输入方式完全取决于为您提供该事件的库的开发人员。 您当然不应该假设它将在与计时器相同的上下文中运行，除非您特别强制它（通过调用 Control.Invoke）。 即使如此，我也不相信你能保证电话订单。
如果您认为重入可能是一个原因，那么解决方案相对简单 - 在两个处理程序（计时器过程和事件）中使用监视器并锁定同一对象。 这将排除这是重入问题的可能性。 如果问题消失，您就知道原因并且已经有了解决方案。 如果问题仍然存在，那么您可以确定这不是重入，您可以将注意力集中在其他地方。
The Windows.Forms timer is going to happen on the UI thread via a call to PostMessage. That is a guarantee. How the "barcode scanned" even comes in is completely up to the developer of the library that's giving you the event. You should certainly not assume that it's going to run in the same context as your timer unless you specifically force it to (via a call to Control.Invoke). Even with that I don't believe you can guaranteee a call order.
If you think re-entrancy might be a cause, the solution is relatively simply - use a Monitor in both handlers (the timer proc and the event) and lock on the same object. That will rule out the possibility that it's a reentrancy issue. If the problem goes away, you know the cause and already have a fix. If the problem persists then you know for certain that it's not reentrancy and you can focus elsewhere.
几乎我使用过的每个条形码扫描组件都运行后台线程，因此我会更仔细地研究它。
Pretty much every barcode scanning component i've worked with runs off a background thread, so i'd look at that more closely.