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

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.

rturner@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.
.

Relevant Pages

  • Re: SetEvent semantics (when nothing is waiting on the event)
    ... 1st SetEvent: 1206497 ... As you can see thread test than gets another 100 ms to run ... Thread test is set to a higher priority then the thread calling SetEvent. ...   Microsoft Embedded Partner ...
    (microsoft.public.windowsce.embedded)
  • Re: ERROR 8007001e when indexing a WMV file
    ... > WaitForSingleObject(hEvent, INFINITE); ... > And now, the OnStatusCallBackImpl class: ... > STDMETHODIMP QueryInterface(REFIID riid, void ** ppv) ... > SetEvent(hEvent); ...
    (microsoft.public.windowsmedia.sdk)