Overhead for Sleep(), WaitFor...(), SetEvent()..

[Gyannea]

Which would be more efficient and accurate to just wait 'x' milliseconds

Sleep(x) or WaitFor SingleObject(hevent, x) where 'hevent' is never signalled?

Also, I have a thread which calls SetEvent() or ResetEvent() depending upon a threshold value of a variable; this variable is updated in a continuously running loop. Since I have no idea how much overhead it takes to call either of these functions, I keep a thread global variable which tracks whether the event is either signalled or unsignalled and call SetEvent() only if the threshold requires a change. There might be an API method of determining if the event is in the signalled or unsignalled state, but I don't know what it is.

Is it worth the effort to minimize the calls to these SetEvent() functions or are they so efficient I am wasting time by making the extra comparisions and the setting of the thread global?

THanks,

Brian

[ahoodin]

Well I for one vote for the use of events and synchronization in general. In reality, Events are faster and more accurate on Windows where the only saving grace seems to be events. Polling for somthing to occur is much less accurate and graceful than events and synchronization objects in general. Windows is a bloated operating system, bloated with all sorts of threads and processes.

HTH,

ahoodin

[Siddhartha]

Which would be more efficient and accurate to just wait 'x' milliseconds

Sleep(x) or WaitFor SingleObject(hevent, x) where 'hevent' is never signalled?

This is not a valid comparison.

WFSO gives the programmer the flexibility to wait for an event to be signalled, and timeout if not. Sleep on the otherhand does not give such flexibility. So, one cannot replace WFSO with Sleep.

Having said this, I must add that Sleep will put your thread into a Wait state - one from which it is non-revivable till the sleep-timesout. So, if one needs this functionality, one would not use WFSO.

Since I have no idea how much overhead it takes to call either of these functions, I keep a thread global variable which tracks whether the event is either signalled or unsignalled and call SetEvent() only if the threshold requires a change.

In general don't worry about Performance without measuring it.

There might be an API method of determining if the event is in the signalled or unsignalled state, but I don't know what it is.

WaitForSingleObject is that API.

if (WaitForSingleObject (hevent, 0) == WAIT_OBJECT_0)
{
	 // The object is signalled.
}
else
{
	 // The object is not signalled, yet.
}

Is it worth the effort to minimize the calls to these SetEvent() functions or are they so efficient I am wasting time by making the extra comparisions and the setting of the thread global?

One shouldn't worry about the time spent to calling these APIs so long as they are being called only when required.

Also, like I said, one does not worry about performance without measuring - in this case, you may write a tiny test application with a thread that is continously stopped and started via events set in the main thread. Use the timer classes in the FAQ to measure time spent calling the APIs - you will see it is insignificant.

In any case, if you genuinely need it - use it. Saving a handful of micro-seconds and cluttering code with unnecessary flags should be avoided at all costs.

[Gyannea]

In many cases I would not be concerned about the overhead, but in this case it is in a high priority thread which runs continuously and is a big CPU drain. It gets called at the sample rate (48K) and some API functions are slow. Since this thread is also handling all the DSP work (lots of FPU and so far only one tap because I have been cheap on the filtering) the calls to SetEvent() may be trivial relative to an FP multiply (of which there are many).

Even though I may only need Sleep(x) functionality, I would take
WFSO(hevent, x) over Sleep() if it is more accurate and more efficient. They both work equally as well even if I don't need the hevent functionality.

Thanks for the hint with getting the state of the event!

Brian

[Siddhartha]

If performance is mission critical and you are using the APIs in question at a rate of say 48KHz, then it is important that you measure by testing them in your system environment before you decide.

The FAQ section has timer classes that you can use to measure time spent.

Found it -

• FAQ: Timer Classes