• 首页 首页 icon
  • 工具库 工具库 icon
    • IP查询 IP查询 icon
  • 内容库 内容库 icon
    • 快讯库 快讯库 icon
    • 精品库 精品库 icon
    • 问答库 问答库 icon
  • 更多 更多 icon
    • 服务条款 服务条款 icon

为什么尽管timeBeginPeriod最小Threading.Timer间隔15毫秒1

用户头像
it1352
帮助1

问题说明

下面的代码片段

    [DllImport("winmm.dll", EntryPoint = "timeBeginPeriod")]
    public static extern uint TimeBeginPeriod(uint uMilliseconds);

    static void Main(string[] args)
    {
        if (TimeBeginPeriod(1) != 0)
            Console.WriteLine("TimeBeginPeriod failed!");

        Console.WriteLine("Sleep");
        Stopwatch sw = Stopwatch.StartNew();
        for (int i = 0; i < 10; i  )
        {
            Thread.Sleep(1);
            Console.WriteLine(sw.ElapsedTicks * 1000d / Stopwatch.Frequency);
            sw.Restart();
        }

        Console.WriteLine("Threading.Timer");
        sw = null;
        System.Threading.Timer t = null;
        int n = 0;

        t = new Timer(state =>
        {
            if (sw == null)
                sw = Stopwatch.StartNew();
            else
            {
                Console.WriteLine(sw.ElapsedTicks * 1000d / Stopwatch.Frequency);
                n  ;
                sw.Restart();
            }
            if (n == 10)
                t.Change(Timeout.Infinite, Timeout.Infinite);
        }, null, TimeSpan.FromMilliseconds(1), TimeSpan.FromMilliseconds(1));
        Console.ReadKey();
    }

会产生如这样的输出:

will produce e.g. this output:

Sleep
0.151834939915548
0.757358826331279
0.786901687225611
0.712520725399457
0.715593741662697
0.798704863327602
0.5724889615859
0.648825479215934
0.436927039609783
0.517873081634677
Threading.Timer
15.5841035662354
14.8620145856526
15.1098812837944
14.4202684978119
15.3883384620112
14.7210748852159
15.307462261265
15.7125416777831
14.5991320125882
15.6035194417168

<据网,例如汉斯帕桑特一个评论, timeBeginPeriod 影响规律(.NET )定时器。那么,为什么我的定时器仍然有这个粗粒度? Thread.sleep代码似乎做就好了。

According to the net, e.g. a comment by Hans Passant, timeBeginPeriod affects the regular (.net) timers. So why does my timer still have this coarse granularity? Thread.Sleep seems to do just fine.

也许相关:这个运行在Windows 7中,64位,.NET 4中,里面的VMWare

Maybe relevant: This runs on Windows 7, 64bit, .net 4, inside VMWare.

正确答案

#1

注释是错误的。我的经验是,多媒体计时器不会影响.NET定时器。也就是说,它不改变其支持的最低时间周期,这似乎是大约15毫秒。它的也许的提高其准确性。也就是说,如果你问16毫秒,你实际上可能得到16毫秒,而不是地方15到30毫秒之间。

The comment is wrong. My experience has been that the multimedia timer does not affect the .NET timers. That is, it doesn't change their minimum supported time period, which appears to be about 15 ms. It might improve their accuracy. That is, if you ask for 16 ms, you might actually get 16 ms and not "somewhere between 15 and 30 ms."

为什么.NET定时器被限制在15毫秒的我也不清楚。

Why the .NET timers are limited to 15 ms is not clear to me.

有关于它的接受的答案一些信息

There's some information about it in the accepted answer here.

如果你正在寻找一个更高的分辨率计时器.NET,你可能不应该使用的多媒体计时器。那些已经pcated Windows API中去$ P $。使用计时器队列计时器。请参阅我的文章:

If you're looking for a higher resolution timer for .NET, you probably shouldn't use the multimedia timers. Those have been deprecated in the Windows API. Use the Timer Queue Timers. See my articles:

  • .NET Timer Resolution
  • Exploring options for better timers
  • Using the Windows Timer Queue API

另一种选择是使用 waitable计时器。全部源代码是可以在 http://www.mischel.com/pubs/waitabletimer.zip

Another option is to use the Waitable Timer. Full source for that is available at http://www.mischel.com/pubs/waitabletimer.zip

这篇好文章是转载于:学新通技术网

  • 版权申明: 本站部分内容来自互联网,仅供学习及演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,请提供相关证据及您的身份证明,我们将在收到邮件后48小时内删除。
  • 本站站名: 学新通技术网
  • 本文地址: /reply/detail/tanhcfiggk
系列文章
更多 icon
同类精品
更多 icon
继续加载