System.Timers.Timer 与 System.Threading.Timer 的线程安全 [英] Thread-safety of System.Timers.Timer vs System.Threading.Timer

问题描述

在本文中:http://msdn.microsoft.com/en-us/magazine/cc164015.aspx 作者声明System.Threading.Timer 不是线程安全的.

In this article: http://msdn.microsoft.com/en-us/magazine/cc164015.aspx the author states that System.Threading.Timer is not thread-safe.

从那以后，这在博客上重复出现，在 Richter 的书CLR via C#"中，关于 SO，但这从来没有道理.

Since then this has been repeated on blogs, in Richter's book "CLR via C#", on SO, but this is never justified.

此外，MSDN 文档保证这种类型是线程安全的."

Moreover the MSDN documentation assures "This type is thread safe."

1) 谁说真话?

2) 如果这是原始文章，什么使 System.Threading.Timer 不是线程安全的，以及它的包装器 System.Timers.Timer 如何实现更多的线程安全?

2) If this is the original article what makes System.Threading.Timer not thread-safe and how its wrapper System.Timers.Timer achieves more thread-safety?

谢谢

推荐答案

不，这不是它的工作方式..NET 异步 Timer 类是完全线程安全的.线程安全的问题在于它不是一个传递属性，它不会使执行的其他代码也成为线程安全的.您编写的代码，而不是 .NET Framework 程序员.

No, that's not the way it works. The .NET asynchronous Timer classes are perfectly thread-safe. The problem with thread-safety is that it is not a transitive property, it doesn't make the other code that's executed thread-safe as well. The code that you wrote, not a .NET Framework programmer.

Windows UI 代码从根本上来说是线程不安全的，这与非常普遍的假设存在同样的问题.事实并非如此，Windows 中的代码是完全线程安全的.问题在于所有运行的代码不是 Windows 的一部分，也不是由 Microsoft 程序员编写的.总是有很多代码，由 SendMessage() 调用触发.它运行程序员编写的自定义代码.或者他没有写的代码，比如某个实用程序安装的钩子.假定程序不会使它变得困难并且只是在一个线程上执行消息处理程序的代码.他通常会这样做，不这样做会给他带来很多的麻烦.

It is the same kind of problem with the very common assumption that Windows UI code is fundamentally thread-unsafe. It is not, the code inside Windows is perfectly thread-safe. The problem is all the code that runs that is not part of Windows and not written by a Microsoft programmer. There's always a lot of that code, triggered by a SendMessage() call. Which runs custom code that a programmer wrote. Or code he didn't write, like a hook installed by some utility. Code that assumes that the program doesn't make it difficult and just executes message handlers on one thread. He usually does, not doing that buys him a lot of trouble.

与 System.Timers.Timer.Elapsed 事件和 System.Threading.Timer 回调相同的问题.程序员在编写该代码时会犯很多错误.它在任意线程池线程上异步运行，接触任何共享变量确实需要锁定以保护状态.很容易被忽视.更糟糕的是，在上一次调用停止运行之前，当代码再次运行时，很容易让自己陷入一堆麻烦.当定时器间隔过低或机器负载过重时触发.现在有两个线程运行相同的代码，很少有好的结局.

Same problem with the System.Timers.Timer.Elapsed event and the System.Threading.Timer callback. Programmers make lots of mistakes writing that code. It runs complete asynchronously on an arbitrary threadpool thread, touching any shared variable really does require locking to protect state. Very easy to overlook. And worse, much worse, very easy to get yourself into a pile of trouble when the code runs again, before the previous invocation stopped running. Triggered when the timer interval is too low or the machine is too heavily loaded. Now there are two threads running the same code, that rarely comes to a good end.

线程很难，十一点消息.

Threading is hard, news at eleven.

这篇关于System.Timers.Timer 与 System.Threading.Timer 的线程安全的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！