On Nov 21 02:52, Mark Geisert wrote: > On 11/21/2024 1:34 AM, Corinna Vinschen wrote: > > On Nov 21 01:12, Mark Geisert wrote: > > > Hi Corinna, > > > > > > On 11/18/2024 4:22 AM, Corinna Vinschen wrote: > > > > Hi Mark, > > > > > > > > > > > > Jon, would you mind to take a look, please? > > > > > > I appreciate the additional eyes, thanks. > > > > > > > This looks good to me, just one question... > > > > > > > > On Nov 12 22:03, Mark Geisert wrote: > > > [...] > > > > > + /* Delay a short time so PdhCQD in caller will have data to > > > > > collect */ > > > > > + Sleep (16/*ms*/); /* let other procs run; one|more yield()s not > > > > > enough */ > > > > > > > > Is there a reason you specificially chose 16 msecs here? > > > > > > > > I'm asking because the usual clock tick is roughly 15.x msecs. > > > > Any Sleep() > 0 but < 16 results in a sleep of a single clock tick, > > > > i.e., > > > > 15 ms. Occassionally 2 ticks, ~31 msecs, 1 to 5 out of 100 runs. > > > > > > > > If you choose a value of 15 msecs, the probability of a Sleep() taking > > > > two ticks is much higher and can be 1 out of 2 Sleep(). > > > ^^^^^^ > > > lower, I think > > > > No, higher. In a low load scenario > > > > Sleep (1) --> < 5% will take two or more clock ticks > > Sleep (15) --> up to 50 % will take two or more clock ticks > > Sleep (16) --> 100% will take two or more clock ticks > > Ah, now I see what you mean. So to maximize the probability it's only one > tick, use "Sleep(1)". Still that's not a guarantee it's one tick. > Have I got that right?
Actually MSDN implies If dwMilliseconds is less than the resolution of the system clock, the thread may sleep for less than the specified length of time. If dwMilliseconds is greater than one tick but less than two, the wait can be anywhere between one and two ticks, and so on. Fact is, I never saw a Sleep(1) taking less than one clock tick, whatever the clock tick is. But yeah, to be on the safe side, Sleep (15L) might be in order, especially if this only occurs once per process. Corinna
