Click here to Skip to main content
15,929,749 members
Home / Discussions / C / C++ / MFC
   

C / C++ / MFC

 
GeneralRe: preemption for 16ms Pin
CPallini24-May-07 2:14
mveCPallini24-May-07 2:14 
GeneralRe: preemption for 16ms Pin
Nir sheffi24-May-07 2:45
Nir sheffi24-May-07 2:45 
GeneralRe: preemption for 16ms Pin
Roger Stoltz24-May-07 2:20
Roger Stoltz24-May-07 2:20 
AnswerRe: preemption for 16ms Pin
Randor 24-May-07 3:28
professional Randor 24-May-07 3:28 
GeneralRe: preemption for 16ms Pin
Roger Stoltz24-May-07 4:24
Roger Stoltz24-May-07 4:24 
GeneralRe: preemption for 16ms Pin
Randor 24-May-07 10:33
professional Randor 24-May-07 10:33 
GeneralRe: preemption for 16ms Pin
Roger Stoltz24-May-07 21:04
Roger Stoltz24-May-07 21:04 
GeneralRe: preemption for 16ms Pin
Randor 25-May-07 4:27
professional Randor 25-May-07 4:27 
Hi Roger,

Roger Stoltz wrote:
The calling thread enter a busy wait state and if the thread is preempted it probably won't run until a time ridiculously greater than the resolution set with ::timeBeginPeriod().


Are you actually implying that several milliseconds pass between thread preemtions? This is incorrect.

I do some kernel driver development so perhaps I have a unique view of this; let me explain.

The maximum measureable time increment is stored in a link list at the kernel level. As you may be aware the kernel keeps track of all processes in an EPROCESS structure. The kernel also has available a struct associated with processes: PROCESS_INFORMATION_CLASS. The behavior and capabilities of each process can be accessed using NtQueryInformation and passing a valid buffer with sufficient size.

If you take a look at the struct SYSTEM_BASIC_INFORMATION:

typedef struct _SYSTEM_BASIC_INFORMATION<br />
    {<br />
    DWORD d00;                      // 0<br />
    DWORD dKeMaximumIncrement;      // x86: 0x0002625A or 0x00018730<br />
    DWORD dPageSize;                // bytes<br />
    DWORD dMmNumberOfPhysicalPages;<br />
    DWORD dMmLowestPhysicalPage;<br />
    DWORD dMmHighestPhysicalPage;<br />
    DWORD dAllocationGranularity;   // bytes<br />
    PVOID pLowestUserAddress;<br />
    PVOID pMmHighestUserAddress;<br />
    DWORD dKeActiveProcessors;<br />
    BYTE  bKeNumberProcessors;<br />
    BYTE  bReserved01;<br />
    WORD  wReserved02;<br />
    }<br />
        SYSTEM_BASIC_INFORMATION,<br />
     * PSYSTEM_BASIC_INFORMATION,<br />
    **PPSYSTEM_BASIC_INFORMATION;<br />
<br />
#define SYSTEM_BASIC_INFORMATION_ \<br />
        sizeof (SYSTEM_BASIC_INFORMATION)<br />


Using the DWORD value dKeMaximumIncrement you can determine the default "timer resolution" for any system.

<br />
SYSTEM_BASIC_INFORMATION sbi;<br />
...<br />
_stprintf((T("Maximum time resolution: %lu (%lu Hz)"), (TICKS_PER_SECOND / sbi.dKeMaximumIncrement) + (TICKS_PER_SECOND % sbi.dKeMaximumIncrement >= sbi.dKeMaximumIncrement >> 1 ? 1 : 0));<br />


The results on my system:

Maximum time resolution: 156250 (64 Hz)

So lets see what this means.

1 second contains 1000 milliseconds. (1000 / 64) == 15.625 milliseconds.

So what this means is if I do a Sleep(1) it will actually sleep about 15.625 milliseconds.

What I am saying is, the timeBeginPeriod() function is modifying the timer resolution at the kernel level which is associated with the process. This will affect all timers. The reason why MM timers function so much better is because they are actually callbacks. A standard WM_TIMER message will still be slowed by the MFC message loop.

Hopefully we all understand timers a bit better. If not I can go into greater detail.

Best regards,
-David Delaune
GeneralRe: preemption for 16ms Pin
Roger Stoltz27-May-07 12:16
Roger Stoltz27-May-07 12:16 
QuestionAnyone know how I can install this addin? Pin
Stick^24-May-07 1:23
Stick^24-May-07 1:23 
AnswerRe: Anyone know how I can install this addin? Pin
David Crow24-May-07 3:12
David Crow24-May-07 3:12 
Questionlstrlen problem Pin
si_6924-May-07 0:36
si_6924-May-07 0:36 
AnswerRe: lstrlen problem Pin
James R. Twine24-May-07 0:49
James R. Twine24-May-07 0:49 
GeneralRe: lstrlen problem Pin
si_6924-May-07 0:52
si_6924-May-07 0:52 
GeneralRe: lstrlen problem Pin
James R. Twine24-May-07 1:00
James R. Twine24-May-07 1:00 
GeneralRe: lstrlen problem Pin
Naveen24-May-07 1:01
Naveen24-May-07 1:01 
QuestionIs my approach feasible? C++ Pin
C_Zealot24-May-07 0:26
C_Zealot24-May-07 0:26 
AnswerRe: Is my approach feasible? C++ Pin
Christian Graus24-May-07 0:50
protectorChristian Graus24-May-07 0:50 
AnswerRe: Is my approach feasible? C++ Pin
James R. Twine24-May-07 0:51
James R. Twine24-May-07 0:51 
GeneralRe: Is my approach feasible? C++ Pin
C_Zealot24-May-07 0:52
C_Zealot24-May-07 0:52 
GeneralRe: Is my approach feasible? C++ Pin
James R. Twine24-May-07 0:57
James R. Twine24-May-07 0:57 
GeneralRe: Is my approach feasible? C++ Pin
C_Zealot24-May-07 1:24
C_Zealot24-May-07 1:24 
GeneralRe: Is my approach feasible? C++ Pin
James R. Twine24-May-07 2:12
James R. Twine24-May-07 2:12 
GeneralRe: Is my approach feasible? C++ Pin
David Crow24-May-07 3:49
David Crow24-May-07 3:49 
GeneralRe: Is my approach feasible? C++ Pin
Michael Sadlon24-May-07 13:10
Michael Sadlon24-May-07 13:10 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.