Wait For Multiple Events

[Guest]

Hello, Newsgroupians:

Again, I'm still migrating from Win32 to C#. I've a question regarding some
event handling in C#.

I have created an EventWaitHandle object and pass that to my worker thread.
When the EventWaitHandle is signaled, I would like my secondary thread to
exit. However, in the thread, I also have another event that I would like to
create, which would be much like a CreateWaitableTimer() in Win32.

In Win32, I could use WaitForMultipleEvents() in my while loop...

bool bDone = FALSE;
while (!bDone)
{
int nIndex = WaitForMultipleEvents(...);

if (nIndex == "Terminate Event") // Pseudocode here
{
bDone = true;
}
else if (nIndex == "Timer Event") // Pseudocode here
{
...
}
}

This would work for me, again, in Win32. Now, I'm trying to create the same
code in C#.

I have come up with a solution I believe is similar to my situation.

// This is my thread delegate
public static void Start(object obj)
{
if (obj.GetType() == typeof(EventWaitHandle))
{
EventWaitHandle ewhTerminateEvent = (EventWaitHandle)obj;
Timer t = new System.Threading.Timer(timerCallBack, null, 0, 1000);

ewhTerminateEvent.WaitOne();
}
}

// This is the timer delegate
public static void timerCallBack(object obj)
{
...
}

This, I believe would work; however, is it possible to create a timer that
will not have a callback function? Therefore, I could emulate the Win32
structure that I have described... (IE: I could use WaitHandle.WaitAny())?

Thank you all for your continued support; your help is always appreciated.


Trecius

 

[Peter Duniho]

[...]
This, I believe would work; however, is it possible to create a timer that
will not have a callback function? Therefore, I could emulate the Win32
structure that I have described... (IE: I could use WaitHandle.WaitAny())?

Yes, WaitHandle.WaitAny() is pretty much the equivalent of
WaitForMultipleEvents().

That said, I don't really understand the implementation you've
suggested in either case. If you've got some sort of processing that
can be done on the tick of a timer, then why do you need the extra
thread at all? You can set up the timer, let it run until you would
have it stop, and then stop it. All of that can be done in the main
thread, without the need to explicitly start any additional thread and
without using waitable events at all.

Pete

 

[Guest]

Thank you, Mr. Duniho. I'll probably do your suggestion and use the lock
keyword.

Also, although I will be doing the System.Timers.Timer to implement my
project as you have suggested, I still have that question: is it possible to
create a timer that will not call a callback function upon ticking? Instead,
it will just set it's event, so I can use it in WaitAny()?

Trecius

[...]
This, I believe would work; however, is it possible to create a timer that
will not have a callback function? Therefore, I could emulate the Win32
structure that I have described... (IE: I could use WaitHandle.WaitAny())?

Yes, WaitHandle.WaitAny() is pretty much the equivalent of
WaitForMultipleEvents().

That said, I don't really understand the implementation you've
suggested in either case. If you've got some sort of processing that
can be done on the tick of a timer, then why do you need the extra
thread at all? You can set up the timer, let it run until you would
have it stop, and then stop it. All of that can be done in the main
thread, without the need to explicitly start any additional thread and
without using waitable events at all.

Pete

 

[Peter Duniho]

Thank you, Mr. Duniho. I'll probably do your suggestion and use the lock
keyword.

Also, although I will be doing the System.Timers.Timer to implement my
project as you have suggested, I still have that question: is it possible to
create a timer that will not call a callback function upon ticking? Instead,
it will just set it's event, so I can use it in WaitAny()?

All the timer classes I'm aware of (all three of them) use an event to
notify the client that the timer period has elapsed.

If you want a sort of timed event, a common technique is to just use
one event, and wait with a timeout value. Then when the thread returns
from the wait, it can check to see if the event is actually set or not
and behave appropriately.

Pete