boost::this_thread::sleep(Microsecond Resolution)

[dominicstreeter@…]

You cannot manage a thread for a process that needs to update at once per millisecond when the resolution of waiting is this low. If a process takes 3 microseconds you can wait arbitrarily for 1.003ms.

If you expand this arbitrary method to a process that takes 0997micro seconds to complete you can spend 1.997ms running a cycle making a process run at half the speed required.

Game Logic and any process that needs to respond on the millisecond has to poll currently and only be timed to account for lag in any well written software it is good practice and economical to wait where appropriate. You can waste 0.999% of a second of energy per second per thread otherwise.

[viboes]

Moved to Feature request as there is no patch attached.

[viboes]

Please could you provide a test that helps to clearly identify the issue? In this way you will help the Boost community.

[dominicstreeter@…]

I am afraid that this ticket is somewhat redundant. The issue was I believed that microsecond timing was necessary to control millisecond interactions precisely on standard hardware.

The reason there is no microsecond timing despite the resolution being addressable now is because even windows 7 professional does not manage or support control of threading on a microsecond level. Its an inherent limitation of the way the operating system is designed. I don't imagine any OS designed for standard commercial use has this as a standard resolution because not all hardware has a high performance counter and so it would be bad practice to try and use such a counter for generic timing. I also found ways around the limitation despite being mildly less precise and efficient they work perfectly. The only real method available is a spin lock cycle.

I apologise for the confusion! In future tickets I will also provide an example application to try and explain the issue.

Thank you for your time!

[viboes]

I guess you are not requesting the library to use spin locks when waiting for some thing to occur. You can do it yourself.

If I've understood we can close the ticket, isn't it?

[dominicstreeter@…]

Yes close the ticket by all means.

[viboes]

See also #6195 Provide the standard time related interface using Boost.Chrono