CODEWITHSUNDEEP
cwindowsmultithreading
agent.smith
agent.smith

Reputation: 9446

sleeping on an event

I have a multi threaded program in which I sleep in one thread(Thread A) unconditionally for infinite time. When an event happens in another thread (Thread B), it wake up Thread-A by signaling. Now I know there are multiple ways to do it. When my program runs in windows environment, I use WaitForSingleObject in Thread-A and SetEvent in the Thread-B. It is working without any issues. I can also use file descriptor based model where I do poll, select. There are more than one way to do it. However, I am trying to find which is the most efficient way. I want to wake up the Thread-A asap whenever Thread-B signals. What do you think is the best option. I am ok to explore a driver based option.

Thanks

Upvotes: 2

Views: 1420

Answers (1)

Arno
Arno

Reputation: 5204

As said, triggering an SetEvent in thread B and a WaitForSingleObject in thread A is fast. However some conditions have to be taken into account:

  • Single core/processor: As Martin says, the waiting thread will preempt the signalling thread. With such a scheme you should take care that the signalling thread (B) is going idle right after the SetEvent. This can be done by a sleep(0) for example.

  • Multi core/processor: One might think there is an advantage to put the two threads onto different cores/processors but this is not really such a good idea. If both threads are on the same core/processor, the time-span between calling SetEventand the return of WaitForSingleObject is much shorter shorter.

  • Handling both threads on one core (SetThreadAffinityMask) also allows to handle the behavior of them by means of their priority setting (SetThreadPriority). You may run the waiting thread at a higher priorty or you have to ensure that the signalling thread is really not doing anything after it has set the event.

  • You have to deal with some other synchronization matter: When is the next event going to happen? Will thread A have completed its task? Most effective a second event can be used to solve this matter: When thread A is done, it sets an event to indicate that thread B is allowed to set its event again. Thread B will effectively first set the event and then wait for the feedback event, it meets the requirment to go idle immedeately.

  • If you want to allow thread B to set the event even when thread A is not finished and not yet in a wait state, you should consider using semaphores instead of events. This way the number of "calls/events" from thread B is kept and the wait function in thread A can follow up, because it is returning for the number of times the semaphore has been released. Semaphore objects are about as fast as events.

Summary:

  • Have both threads on the same core/cpu by means of SetThreadAffinityMask.

  • Extend the SetEvent/WaitForSingleObject by another event to establish a Handshake.

  • Depending on the details of the processing you may also consider semaphore objects.

Upvotes: 2

Related Questions