Modify

Opened 7 years ago

Closed 6 years ago

#4773 closed Feature Requests (worksforme)

boost::this_thread::sleep(Microsecond Resolution)

Reported by: dominicstreeter@… Owned by: Anthony Williams
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 (0)

Change History (6)

comment:1 Changed 7 years ago by viboes

Type: PatchesFeature Requests

Moved to Feature request as there is no patch attached.

comment:2 Changed 7 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 7 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 7 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 7 years ago by dominicstreeter@…

Yes close the ticket by all means.

comment:6 Changed 6 years ago by viboes

Resolution: worksforme
Status: newclosed

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

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Anthony Williams.
The resolution will be deleted.

Add Comment


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

 
Note: See TracTickets for help on using tickets.