Re: SetEvent semantics (when nothing is waiting on the event)

On May 21, 3:50 am, "Michel Verhagen (eMVP)" <mic...@xxxxxxxxxx>
wrote:
Just verified the behaviour is not different on CE 6.0:

BOOL g_bStop = FALSE;

DWORD WINAPI Test(LPVOID lpParameter)
{
     HANDLE hEvent = (HANDLE)lpParameter;
     while(!g_bStop)
     {
         WaitForSingleObject(hEvent, INFINITE);
         if (g_bStop)
             break;
         RETAILMSG(1, (L"Event set, starting work %d\r\n", GetTickCount()));
         for(DWORD n=0; n<0xFFFFFFF; n++);
         RETAILMSG(1, (L"Work done: %d\r\n", GetTickCount()));
     }
     return 0;

}

int WINAPI WinMain(HINSTANCE hInstance,
                    HINSTANCE hPrevInstance,
                    LPTSTR    lpCmdLine,
                    int       nCmdShow)
{
     HANDLE hEvent = CreateEvent(NULL, FALSE, FALSE, NULL);

     HANDLE hThread = CreateThread(NULL, 0, Test, (LPVOID)hEvent, 0, NULL);

     Sleep(100);

     RETAILMSG(1, (L"1st SetEvent: %d\r\n", GetTickCount()));
     SetEvent(hEvent);
     // Make sure thread gets scheduled
     Sleep(1);
     RETAILMSG(1, (L"2nd SetEvent: %d\r\n", GetTickCount()));
     // Now set the event while Test is in tight loop
     SetEvent(hEvent);
     RETAILMSG(1, (L"Returned at : %d\r\n", GetTickCount()));

     g_bStop = TRUE;
     SetEvent(hEvent);
     WaitForSingleObject(hThread, INFINITE);
     CloseHandle(hThread);
     CloseHandle(hEvent);

     return 0;

}

Output:

1st SetEvent: 1206497
Event set, starting work 1206498
2nd SetEvent: 1206599
Returned at : 1206799
Work done: 1217430

When we set the event the first time and Sleep for 1 ms we make sure the
Test thread actually starts it's work (at 1206498). After exactly 100 ms
(+1 ms of the sleep) our main thread gets scheduled again. We then set
the event for the 2nd time. We set it while thread Test is still in its
tight loop. As you can see thread test than gets another 100 ms to run
and after that time our main thread gets scheduled again. Note that the
100 ms is the default thread quantum.

There are several reasons why SetEvent will not return before the tight
loop in thread test is finished:

1. Thread test is set to a higher priority then the thread calling SetEvent.
2. Thread test has it's thread quantum set to 0 (run to completion).

Good luck,

Michel Verhagen, eMVP
Check out my blog:http://GuruCE.com/blog

  GuruCE Ltd.
  Microsoft Embedded Partner
 http://GuruCE.com
  Consultancy, training and development services.



Michel Verhagen (eMVP) wrote:
No, SetEvent will return immediately, but the state of an auto-reset
event object remains signaled until a single waiting thread is released,
at which time the system automatically sets the state to nonsignaled. If
no threads are waiting, the event object's state remains signaled.

Good luck,

Michel Verhagen, eMVP
Check out my blog:http://GuruCE.com/blog

 GuruCE Ltd.
 Microsoft Embedded Partner
 http://GuruCE.com
 Consultancy, training and development services.

rtur...@xxxxxxxxxx wrote:
I've got a program that runs on WinCE 6.0.  It uses an (auto-reset)
event to signal a thread to start processing data.  The loop for this
data processing thread looks like:

while (!fExit)
{
    WaitForSingleObject(hEvent);
    DoSomeProcessing();
}

If I call SetEvent(hEvent) while the thread is busy inside
DoSomeProcessing(), my expectation is that SetEvent() would just set
hEvent to signalled, and then return.  However, it appears that in
this case SetEvent() doesn't return until until it can actually set
one thread running, so it waits for the call to
WaitForSingleObject(hEvent) to be hit before it returns.

Can someone confirm this is how SetEvent on WinCE 6.0 works?  Or
doesn't?  This seems different that how SetEvent works on XP / Vista.- Hide quoted text -

- Show quoted text -

Okay, I figured out the issue. There was a thread priority inversion
issue going on. The thread doing the SetEvent() was running at below
normal priority, and the thread doing the WaitForSingleObject was at
time critical priority. If I set both to normal priority I'm getting
latencies I'd expect. Thanks for the replies -- totally appreciated.
.