我有一个关于线程在C＃中的一个小问题。 出于某种原因，我的线速度从32毫秒延迟16ms的延迟当我打开浏览器，当我关闭浏览器就GOED回为32ms。我使用Thread.sleep代码（1000至1060年）的延迟。 有人可以解释为什么发生这种情况，也许提出一个可行的解决方案？

 使用系统;
 使用System.Collections.Generic;
 使用System.Linq的;
 使用System.Text;
 使用的System.Threading;

 命名空间ConsoleApplication2
 {
     类节目
     {
         静态布尔活着;
         静态线程的线程;
         静态的DateTime最后;

         静态无效的主要（字串[] args）
         {
             活着= TRUE;
             线程=新主题（新的ThreadStart（环路））;
             thread.Start（）;

             Console.ReadKey（）;
         }

         静态无效的循环（）
         {
             最后= DateTime.Now;

             而（活着）
             {
                 日期时间电流= DateTime.Now;
                 时间跨度跨度=电流 - 最后;
                 最后=电流;

                 Console.WriteLine（{0}毫秒，span.Milliseconds）;
                 Thread.sleep代码（1000至1060年）;
             }
         }
     }
 }
 

解决方案

只是一个职位，以确认马修的正确答案。 Thread.sleep代码的精确度（）是由时钟中断速率上视窗的影响。默认情况下它蜱每秒64次，每15.625毫秒一次。睡眠（）当这样的中断发生时只能完成。这里的精神形象是一个诱发单词休眠，处理器其实睡着了，不执行code。只有时钟中断将会再次唤醒它，继续执行你的code。

您选择的60分之1000是一个非常不幸的一个，那要求16毫秒。只是有点超过15.625所以你永远醒备份后至少2个滴答：2×15.625 = 31毫秒。你测什么。

这中断率然而，不固定的，它可以由一个程序改变。它是通过调用CreateTimerQueueTimer（）或传统timeBeginPeriod（）。一般浏览器有这样做的必要。简单的东西作为一个动画GIF需要一个更好的计时器，因为GIF帧时间为10毫秒为单位指定的。或者一般地任何多媒体相关的操作需要它。

程序这样做的一个非常丑陋的副作用是，这增加了时钟中断率具有系统范围的影​​响。就像它在你的程序一样。您的计时器突然得了准确，你实际上得到你要求的，16毫秒的睡眠时间。因此，Chrome浏览器正在改变速度，大概，1000蜱每秒。最大支持。

您可以通过拾取睡眠时间，这是一个更匹配的默认中断率避免这个问题。如果你问15，那么你会得到15.625和Chrome可能没有这方面的影响。图31是下一个甜蜜点。诸如此类，15.625的整数倍，并四舍五入。

I have a small problem regarding threading in C#. For some reason my thread speeds up from 32ms delay to 16ms delay when i open Chrome, when i close Chrome it goed back to 32ms. I'm using "Thread.Sleep(1000 / 60)" for the delay. Can somebody explain why this is happening, and maybe suggest a possible solution?

 using System;
 using System.Collections.Generic;
 using System.Linq;
 using System.Text;
 using System.Threading;

 namespace ConsoleApplication2
 {
     class Program
     {
         static bool alive;
         static Thread thread;
         static DateTime last;

         static void Main(string[] args)
         {
             alive = true;
             thread = new Thread(new ThreadStart(Loop));
             thread.Start();

             Console.ReadKey();
         }

         static void Loop()
         {
             last = DateTime.Now;

             while (alive)
             {
                 DateTime current = DateTime.Now;
                 TimeSpan span = current - last;
                 last = current;

                 Console.WriteLine("{0}ms", span.Milliseconds);
                 Thread.Sleep(1000 / 60);
             }
         }
     }
 }

Just a post to confirm Matthew's correct answer. The accuracy of Thread.Sleep() is affected by the clock interrupt rate on Windows. It by default ticks 64 times per second, once every 15.625 msec. A Sleep() can only complete when such an interrupt occurs. The mental image here is the one induced by the word "sleep", the processor is in fact asleep and not executing code. Only that clock interrupt is going to wake it up again to resume executing your code.

Your choice of 1000/60 was a very unhappy one, that asks for 16 msec. Just a bit over 15.625 so you'll always wake back up at least 2 ticks later: 2 x 15.625 = 31 msec. What you measured.

That interrupt rate is however not fixed, it can be altered by a program. It does so by calling CreateTimerQueueTimer() or the legacy timeBeginPeriod(). A browser in general has a need to do so. Something simple as animating a GIF requires a better timer since GIF frame times are specified with a unit of 10 msec. Or in general any multi-media related operation needs it.

A very ugly side-effect of a program doing this is that this increased clock interrupt rate has system-wide effects. Like it did in your program. Your timer suddenly got accurate and you actually got the sleep duration you asked for, 16 msec. So Chrome is changing the rate to, probably, 1000 ticks per second. The maximum supported.

You can avoid this problem by picking a sleep duration that's a closer match to the default interrupt rate. If you ask for 15 then you'll get 15.625 and Chrome cannot have an effect on that. 31 is the next sweet spot. Etcetera, integer multiples of 15.625 and rounded down.