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

问题描述

在这篇文章：<一个href="http://msdn.microsoft.com/en-us/magazine/cc164015.aspx">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.

此后这一直重复在博客上，在里希特的书CLR通过C＃，就这样，不过这从来都不是有道理的。

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异步定时器类是完全线程安全的。线程安全的问题是，它不是过渡性质，它不会使的等的多数民众赞成执行的线程安全和code。在code，你写的，而不是.NET框架的程序员。

No, that's not the way it works (again). 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用户界面code是根本线程安全的同样的问题。实在不行，里面的Windows的code是完全线程安全的。问题是所有运行的是code的没有的Windows的一部分，而不是写的微软程序员。总是有那code进行的很多的，通过SendMessage函数（）调用触发。它运行定制code，一个程序员写的。或者code，他不写，像一些实用工具安装的挂钩。 code，它假定程序不让人很难，只是在执行一个线程的消息处理程序。他平时不，不这样做，给他买一个的很多的麻烦。

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回调。程序员做的很多错误编写code 的。它以异步方式在任意线程池线程运行完成后，触摸任何共享变量确实需要锁定保护状态。很容易忽略。更糟糕的是，差多了，很容易让自己陷入一堆麻烦时，code运行时的再次的，在previous调用停止运行之前。触发当定时器时间间隔过低或机器负载过重。现在还有的两个的运行相同的code，很少涉及到一个好下场的线程。

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的的线程安全VS System.Threading.Timer的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！