Modify

Ticket #4773 (closed Feature Requests: worksforme)

Opened 4 years ago

Last modified 3 years ago

boost::this_thread::sleep(Microsecond Resolution)

Reported by: dominicstreeter@… Owned by: anthonyw
Milestone: To Be Determined Component: thread
Version: Boost 1.44.0 Severity: Optimization
Keywords: Timing Microsecond Millisecond Precision Resolution Economic Practice Cc: viboes

Description

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.

Attachments

Change History

comment:1 Changed 4 years ago by viboes

  • Type changed from Patches to Feature Requests

Moved to Feature request as there is no patch attached.

comment:2 Changed 4 years ago by viboes

  • Cc viboes added

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

comment:3 Changed 4 years ago by 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!

comment:4 Changed 4 years ago by 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?

comment:5 Changed 4 years ago by dominicstreeter@…

Yes close the ticket by all means.

comment:6 Changed 3 years ago by viboes

  • Status changed from new to closed
  • Resolution set to worksforme

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

View

Add a comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
The resolution will be deleted. Next status will be 'reopened'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.