Re: [boost] boost::thread dependency on boost::chrono (windowsimplementation)

Subject: Re: [boost] boost::thread dependency on boost::chrono (windowsimplementation)
From: Philip Bennefall (philip_at_[hidden])
Date: 2013-06-28 06:10:46

----- Original Message ----- 
From: "Klaim - Joël Lamotte" <mjklaim_at_[hidden]>
To: "Boost Developers List" <boost_at_[hidden]>
Sent: Friday, June 28, 2013 11:57 AM
Subject: Re: [boost] boost::thread dependency on boost::chrono 
(windowsimplementation)

On Fri, Jun 28, 2013 at 7:42 AM, Vicente J. Botet Escriba <
vicente.botet_at_[hidden]> wrote:

> Unfortunately I don't know how to implement a real steady_clock on windows
> platform, and I was wondering if it shouldn't be removed.
> Of course if someone knows how to do it, patches are welcome.
>

I think I have pointed a very long time ago (but I can't find the
discussion) that Ogre3D had a steady clock for years.
If I remember correctly my message was discussed and waived but I'm not
sure what was the reason exactly.
Anyway the code is open-source under MIT license so you could get inspired
from it:

https://bitbucket.org/sinbad/ogre/src/0bba4f7cdb953c083aa9e3e15a13857e0988d48a/OgreMain/src/WIN32/OgreTimer.cpp?at=default

I've used this code for years without any problem after I hit the issue of
processor switches.
As you can read, on Windows desktops the query will be done always on one
core.
I have no clear idea of the implications on performance, but I never had
performance problem related to this so far.

Joel Lamotte

Hello Joel,

Personally I have used QueryPerformanceCounter for years on many systems 
without issues, provided I implement some code to make sure it only runs on 
one core. It is when the scheduler switches cores for the thread that does 
the timing that I ran into problems. I have the following in my code:

void Timer_LimitThread()
{
HANDLE hCurrentProcess = GetCurrentProcess();
DWORD_PTR dwProcessAffinityMask = 0;
DWORD_PTR dwSystemAffinityMask = 0;

if( GetProcessAffinityMask( hCurrentProcess, &dwProcessAffinityMask, 
&dwSystemAffinityMask ) != 0 && dwProcessAffinityMask )
{
DWORD_PTR dwAffinityMask = ( dwProcessAffinityMask & 
((~dwProcessAffinityMask) + 1 ) );

HANDLE hCurrentThread = GetCurrentThread();
if( INVALID_HANDLE_VALUE != hCurrentThread )
{
SetThreadAffinityMask( hCurrentThread, dwAffinityMask );
CloseHandle( hCurrentThread );
}
}
CloseHandle( hCurrentProcess );
}

I am not sure whether this actually fixes the problem you describe, but I 
thought I should at least throw the idea out there.

Kind regards,

Philip Bennefall