Rule of thumb is that humans notice interface delays only starting from about 250ms.
I found that if I put "sleep(1);" in thread.Execute's while-loop, the CPU usage of the application is nearly 0%, but when I put "yield;" instead, the CPU usage if about 25%.
BTW, I have tested that sleep(0) is similar to yield.
I found that if I put "sleep(1);" in thread.Execute's while-loop, the CPU usage of the application is nearly 0%, but when I put "yield;" instead, the CPU usage if about 25%.There is a lot of fun to be had with Sleep(0). From what you typed, you have a computer with a quad-core. If your computer had 8 cores, the CPU usage would have been slightly above 12.5%. (presuming the machine is not very busy with other processes.) Keep digging into Sleep(0) and you'll learn a lot about how Windows works, particularly about how it schedules CPU time to processes.
So, I think if a thread is NOT very time-critical, one should use sleep(1) to reduce the CPU usage.You got that right :)
I found that if I put "sleep(1);" in thread.Execute's while-loop, the CPU usage of the application is nearly 0%, but when I put "yield;" instead, the CPU usage if about 25%.
Yep, but your Sleep(1) does not freeze the program for 1ms, and for much longer. It probably stops the program for about 16ms. The clock's resolution is not so high, so if you need to increase it, use the TimeBeginPeriod and TimeEndPeriod functions from the MMSystem unit.
Sleep(0) does nothing, does not stop the program, so the processor's power consumption will still be full. The smallest actually working value for Sleep procedure is 1, and the real shortest break is that lasting 2ms.
For what I know, I just saw TEvent for Windows targeted cross-compilation.
As for the search for CreateEvent, ResetEvent, etc., methods encapsulated in a Windows TEvent component, I didn't see it for a Linux target: I only found equivalent APIs in cthreads.pp.
Is there a TEvent for Linux in Lazarus?
But sleep works using the scheduler timer, probably some HPET thing, and not the RTC.
Please inform Microsoft https://docs.microsoft.com/en-us/windows/desktop/api/synchapi/nf-synchapi-sleep
But sleep works using the scheduler timer, probably some HPET thing, and not the RTC.
Explain one thing to me. My platformer uses Sleep between frames to make delays (few ms). I checked how it works on Win10. Without using the TimeBeginPeriod function, the game maintains 41fps, and if I call it with a minimum period, it maintains 60fps.
It probably stops the program for about 16ms.
Results of some quick research on timing in Win32 (http://www.geisswerks.com/ryan/FAQS/timing.html) — see the penultimate section. Old article, but helped me a lot.
I know it's not like Sleep(0) actually does anything. My point was that it does not freeze the program/thread, so 25% of the power consumption (100% of the core) is the expected value.
Please inform Microsoft https://docs.microsoft.com/en-us/windows/desktop/api/synchapi/nf-synchapi-sleep
The scheduler's timer is accurate, the preemptive scheduler is not :-)
I reacted to yourQuoteIt probably stops the program for about 16ms.
Based on old 18.2 clock timer resolutions, which is simply not true. Since Nehalem, hpet timers are in uncore and constant in frequency and quite precise. Windows will use whatever resources it have to try to keep it short.
[…]
Too old, one of the two test systems is win98 for christ sake!
My point was that it does not freeze the program/thread,why sleep?
My point was that it does not freeze the program/thread,why sleep?
can't you just use this code instead?
Also note Sleep(0) means "relinquish time slice"That's what it's _supposed_ to mean.
So Sleep(0) is what should be done....That's what people who believe the documentation think.
This is weird, but true... Sleep(0) is a special case.... for threading...You got that right. It is a _very_ special case.
why sleep?
can't you just use this code instead?
That's what it's _supposed_ to mean.
Nope, you can't use Application.ProcessMessages from a thread. There will be a deadlock (or other disaster) if you call it in a context of thread.I've always used application.processmessages on synchronize.
I've always used application.processmessages on synchronize.
Okay, but what is the purpose of calling this method?to prevent core freezing.
It's not really hard either. A few small, well chosen, trivial test programs are very revealing about Sleep(0) and the Windows scheduler.That's what it's _supposed_ to mean.
It's not as easy as it seems. What else to understand what these words mean, and what else to know what they actually mean in practice.
And the documentation does not explain this in any way.That is true. There are plenty of APIs to which that comment applies to some degree. Another example of one like that, a very simple one that comes to mind at this time, is GetWindowModuleFileName https://docs.microsoft.com/en-us/windows/desktop/api/winuser/nf-winuser-getwindowmodulefilenamea (https://docs.microsoft.com/en-us/windows/desktop/api/winuser/nf-winuser-getwindowmodulefilenamea). What the documentation leads you to believe about what it does and, what it actually does, are two different things. That said it occasionally does what the documentation says. <chuckle>
Maybe give the application a chance to process OnIdle "messages" since the application thread may be suspended due to an absence of OS message activity ?I've always used application.processmessages on synchronize.
Okay, but what is the purpose of calling this method?
I don't think this has changed since the 90's. If so, I am wrong for a very long time (since NT3.5/Win3.1).
In Unix like systems this works different: that simply does not misuse a timer signal for a shorthand to a semaphore...
The first thing to do is avoid sleeps alltogether, since they are an indication of polling and latency.That is bad advice. Sleep(n) where n > 0 is simply a mechanism to inform the scheduler the thread does not require CPU cycles.
I've attached an example project showing a scenario where sleep(0) has an effect as opposed to no sleep at allThat is not a conclusion that can be derived from the example you attached.
The first thing to do is avoid sleeps alltogether, since they are an indication of polling and latency.That is bad advice. Sleep(n) where n > 0 is simply a mechanism to inform the scheduler the thread does not require CPU cycles.
One of the nice things about Sleep is that it doesn't require the application to create an object to wait on and the O/S to maintain and pay attention to it. Sleep is very low overhead and lets the O/S know that for n milliseconds, the thread doesn't need any attention.
In addition to that, there are events for which there are no available objects that can be created to wait on. e.g, at least in Windows, you can't wait on some window that belongs to another process to finish painting itself.
Polling, if done well, can be more efficient than waiting on an object (which the O/S scheduler has to pay attention to.) A good combination of SRW locks and Sleep can produce much better results than using objects to wait on. If you doubt that, compare the performance of Mutexes and Critical sections. Using mutexes is higher overhead and roughly 1/20 the performance and a lot more work for the O/S.
I can't see what you mean. I've attached an image with the output. Left is no sleep, right is with sleep.I cannot comment on the screenshot you posted because you didn't post the code that produced it. The modified example I posted, shows very clearly that sleep has little to no effect on thread switching in that case.
As you see left is reading out the old value many times while right it reads more evenly
Also, I have to mention writeln, which uses locks to make sure the output buffer isn't accessed at the same time by other threads and when the buffer does go full eventually will cause a full sleep till the buffer is processed(while holding the lock), so not sure if you want to use that to show of threading or ever use in anything that's cpu intensiveThere will not be a "full sleep" until the buffer is processed. When both threads send text to conhost.exe (which is a separate process), one thread will be blocked until the request to write from the other thread is complete but, that doesn't imply a thread switch to the other thread in the same process.
Then it shouldn't either not be running (in case it only polled),That's what "sleep" is for, to "not run", to let the scheduler know that the thread doesn't need any clock cycles.
or it should block to the next time it should actually do something.When the thread is awaken, it will do something. In the meantime, it doesn't use up system resources and scheduler clock cycles with synchronization objects.
Sleep(n) is not just saying that you don't need cycles now, but at the same time a request to get them in "n".No, that is not correct. Sleep is not a request to get clock cycles after n milliseconds have elapsed. The thread may, or may not, get clock cycles after n milliseconds. This is the reason why sleep is considered by many to be "inaccurate", because of the mistaken belief that after the time has elapsed the scheduler will run it.
My reasoning is that THAT should be avoided if possible.What should be avoided is to cause the scheduler to waste clock cycles on a thread that doesn't need them. That's what sleep(n) does.
Objects can be reused. For the variation in overhead I'd like a reference. Afaik in both cases it is a scheduler lock on a condition.Yes, synchronization objects can definitely be reused. The overhead is simple, a mutex causes a ring transition from ring3 to ring0 and requires scheduler clock cycles to determine if the mutex is signaled and then additional clock cycles once it's been signaled to find which thread(s) was/were waiting for the object to be signaled.
There are always exceptions, and that was never denied. We are talking about the general case here. (and even then there is a lot possible with waitmultiplemessage variants)Marco, the point was that using Sleep is a good thing, and not something to be avoided. A thread should let the processor know when it doesn't need attention. The thread that definitely should NOT be calling "sleep" is the thread that pumps messages.
Afaik mutexes that are cross-apllication (global) in nature are fairly slow. Non named ones used within one process afaik aren't.I haven't tested the performance of unnamed mutexes but, if this is correct https://stackoverflow.com/questions/1666653/are-mutexes-really-slower (https://stackoverflow.com/questions/1666653/are-mutexes-really-slower) then unnamed mutexes are still kernel objects with all the associated overhead of a named mutex.
Post the program that produced that output.
QuotePost the program that produced that output.
the code you posted without any changes
https://youtu.be/3nHpf54_bwA
it's possible windows 10 'fixed' sleep. I tested it on an old win7 and there there is no difference between no sleep and sleep(0) (also slow cpu but not sure if that matter)