Events disappearing
-
Hi All, The problem I seem to be having is that events seem to be disappearing (i.e. no-one gets them). I have essentially 3 threads in a console application. The "control" class creates a number of events like:
m_stSyncEvents.m_hSyncRxStart = ::CreateEvent (NULL, FALSE, FALSE, NULL);Later on, the code creates two threads. These threads then do a::SetEvent (m_stSyncEvents.m_hSyncRxStart)when they finished their initialisation. The threads themselves have a common thead function and use the fastdelegate code to call back into the class. After the threads are created I do a:::WaitForMultipleObjects (2, ahThreadSync, TRUE, INFINITE);withahThreadSyncbeing handles to the event handles per thread. The problem now comes that the second task that is created is not sending events or receiving them 100%. 2 /10 times it works perfectly. However the other times, the second thread does not send the event (but SetEvent is not failing) or it does not receive the abort event from the control class, which is created in a similar way except it is in manual reset mode. In each case the thread is running. Any Ideas?? regards, Rich "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far the Universe is winning." -- Rich Cook -
Hi All, The problem I seem to be having is that events seem to be disappearing (i.e. no-one gets them). I have essentially 3 threads in a console application. The "control" class creates a number of events like:
m_stSyncEvents.m_hSyncRxStart = ::CreateEvent (NULL, FALSE, FALSE, NULL);Later on, the code creates two threads. These threads then do a::SetEvent (m_stSyncEvents.m_hSyncRxStart)when they finished their initialisation. The threads themselves have a common thead function and use the fastdelegate code to call back into the class. After the threads are created I do a:::WaitForMultipleObjects (2, ahThreadSync, TRUE, INFINITE);withahThreadSyncbeing handles to the event handles per thread. The problem now comes that the second task that is created is not sending events or receiving them 100%. 2 /10 times it works perfectly. However the other times, the second thread does not send the event (but SetEvent is not failing) or it does not receive the abort event from the control class, which is created in a similar way except it is in manual reset mode. In each case the thread is running. Any Ideas?? regards, Rich "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far the Universe is winning." -- Rich CookAre you suggesting BOTH of the 'alternate' threads are each setting m_stSyncEvents.m_hSyncRxStart? If so, you need two separate events. Each of those worker threads should set its own private event, and the waiting thread needs to wait on both of those separate events. I would also have each thread own it own abort event. People that start writing code immediately are programmers (or hackers), people that ask questions first are Software Engineers - Graham Shanks
-
Are you suggesting BOTH of the 'alternate' threads are each setting m_stSyncEvents.m_hSyncRxStart? If so, you need two separate events. Each of those worker threads should set its own private event, and the waiting thread needs to wait on both of those separate events. I would also have each thread own it own abort event. People that start writing code immediately are programmers (or hackers), people that ask questions first are Software Engineers - Graham Shanks
Blake Miller wrote:
Are you suggesting BOTH of the 'alternate' threads are each setting m_stSyncEvents.m_hSyncRxStart?
No. Each thread has its own event. There is a separate event created per thread object.
Blake Miller wrote:
I would also have each thread own it own abort event.
The design was for a simplified exit mechanism. The threads wait on multiple events depending on what it is currently upto. Having a single 'abort' event that could trigger all threads to exit, was the reason for this. "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far the Universe is winning." -- Rich Cook