views:

34

answers:

2

Hi all.

I have a thread that needs to dispatch a message (a simulated mouse event that it sends using SendInput) as soon as it's generated. I want this to happen in a loop where there is no sleep; adding any sleep hurts performance as I basically want the events to go in to the event loop immediately once they have been generated. Of course I also don't want the loop in the consumer thread to hog all the cpu so I can't just keep it running, although this gives me good performance.

As far as I understand this, the task is to make the consuming thread to wait for something that signals that the producing thread has provided something to dispatch (?) but how to best do this? I think I need something like two mutexes if I want to make the two threads mutually exclusive; consumer waits for the producer and the producer continues as soon as the consumer resumes running? Didn't really get this working so far and I'm really not sure how to best do this; CriticalSections vs. mutexes, something entirely different?

The reason I don't want to call SendInput from the producer thread is that that thread (the 'main thread'?) actually runs in response to a mouse move message, intercepted by a mouse hook, and sending more mouse messages from that thread didn't allow the thread to finnish before the simulated mouse move event was processed, messing things for me. As I suspected, moving the SendInput call to another thread so that the original thread could finish out of the way fixed the problem but now I need to make the consumer more responsive; mouse messages keep coming at a good pace I suppose since just a 1 ms Sleep made the loop too slow and message processing started lagging; all works well if I have no sleep.

Thanks.

+2  A: 

Sounds like you want to use win32 event objects instead of mutexes or critical sections. See the docs here. The event functions allow a thread to wait on a condition that can be signaled from another thread.

bshields
Thanks. Will look into it for future reference although it seems that this time the sleep will work for me after all; it was a few cout printouts that ended up executed when mouse input was dispatched, slowing down execution :s
72con
+1  A: 

Windows threads support message queues - usually used for windows messages but completely usable for messaging between worker threads. PostThreadMessage can be used in the Hook Proc to post messages to another thread for processing.

The worker thread can do a normal GetMessage loop to extract messages to process - rather than passing them on to DispatchMessage as you would in a UI thread you simply check the HWND is NULL in the message structure indicating its a thread message, then process the message yourself. In the case of potential message flooding PeekMessage can be used to cull any outstanding messages from the queue.

Chris Becke
Ok, that's good to know. In my case, however, I need to use SendInput (I need the OS to move the cursor on the screen) so the worker can't do all the processing on the 'message' it gets from the UI thread. It should 1) get the coordinates, 2) call SendInput and 3) wait for the next coordinates from the UI thread when the cursor needs to be repositioned again. Preferably, I'd like to ensure the UI thread does not even finish processing the original mouse move msg before calling SendInput.This is for a simulated cursor where the actual cursor should always be put back every time it is moved.
72con
And one more question if someone can explain this to me; previously I had the UI thread call SendInput when there was a mouse move message and the cursor needed to be repositioned on the screen. Now I can't help but to ask myself why that didn't result in a deadlock; both messages did get processed (recursively). Isn't calling SendInput from the UI thread exactly something that should guarantee a halt?
72con