Boost C++ Libraries: Ticket #12744: winapi::set_timer_resolution inadvertently changes timer resolution (Windows) https://svn.boost.org/trac10/ticket/12744 <p> boost::interprocess::ipcdetail::spin_wait calls get_system_tick_in_highres_counts(), which ultimately calls winapi::set_timer_resolution() to get the current timer resolution. However, this changes the timer resolution inadvertently. </p> <p> I verified this with <a class="missing wiki">PwrTest</a>.exe (<a class="ext-link" href="https://msdn.microsoft.com/windows/hardware/drivers/devtest/pwrtest"><span class="icon">​</span>https://msdn.microsoft.com/windows/hardware/drivers/devtest/pwrtest</a>). </p> <p> Can we use winapi::query_timer_resolution() instead of winapi::set_timer_resolution()? </p> en-us Boost C++ Libraries /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/12744 Trac 1.4.3 Ion Gaztañaga Thu, 19 Jan 2017 23:43:14 GMT <link>https://svn.boost.org/trac10/ticket/12744#comment:1 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/12744#comment:1</guid> <description> <p> In theory the second parameter is set_timer_resolution is zero, which should not change the current resolution. But if you verified the change, then your suggestion seems the right way to go. </p> </description> <category>Ticket</category> </item> <item> <dc:creator>Ion Gaztañaga</dc:creator> <pubDate>Thu, 19 Jan 2017 23:51:08 GMT</pubDate> <title>status changed; resolution set https://svn.boost.org/trac10/ticket/12744#comment:2 https://svn.boost.org/trac10/ticket/12744#comment:2 <ul> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">fixed</span> </li> </ul> <p> Fixed in commit: </p> <p> <a class="ext-link" href="https://github.com/boostorg/interprocess/commit/b3dd777e5ce41d40bbcc3920323ff4d85fc68c0e"><span class="icon">​</span>https://github.com/boostorg/interprocess/commit/b3dd777e5ce41d40bbcc3920323ff4d85fc68c0e</a> </p> Ticket anonymous Thu, 01 Mar 2018 19:49:37 GMT <link>https://svn.boost.org/trac10/ticket/12744#comment:3 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/12744#comment:3</guid> <description> <p> I know this bug is closed, but I wanted to add a comment explaining the previous behavior. I just spent 2 days tracking down why our timer resolution was getting messed up. (We were using a previous Boost version). </p> <p> First of all, the call to <a class="missing wiki">NtSetTimerResolution</a> is a private ntdll function. Not an API you should be using, or especially assuming the behavior of. There is no official documentation. The second argument (called 'set') that was false, is not meant to be a benign query of the timer resolution. Instead, it 'unsets' the process's request for a custom timer resolution. This would be used by the proper Public api in winmm.dll and the calls for timeBeginPeriod/timeEndPeriod. </p> <p> By calling <a class="missing wiki">NtSetTimerResolution</a> with set=false. Future calls to timeBeginPeriod/timeEndPeriod had no effect if there was already a timeBeginPeriod call outstanding. Most likely winmm (which likely tracks the pairs of timeBeginPeriod/timeEndPeriod calls) was now out of sync with its interaction with ntdll. </p> </description> <category>Ticket</category> </item> </channel> </rss>