Someone suggested to me to use Call Back Functions to implement a timer to run in the background while my Server application reads input from clients. I tried looking at explanations online, but was hoping if someone could give me a simpler analogy.
Thanks.
There are two separate ways to implement a timer using callbacks in Windows, SetTimer and timeSetEvent. The basics are:
SetTimer uses messages, even if you use a callback (the callback function is invoked as a result of processing a message). So SetTimer isn't viable if you don't run a message pump.
Callbacks are called by the operating system, which doesn't know a C++ "this" pointer from a hole in the ground, so your callback either has to be a global C-style function or a static member.
timeSetEvent is part of the "multimedia" timer family, and doesn't require a message pump. The observations about the callback function signature above still apply though. The lack of requirement for a message pump can be important if you're writing a console app though.
You might also consider threading and CreateWaitableTimer, but I don't use waitable timers very often so can't comment on them.
If you need to do work in the background, then threading can be a much more elegant way to address the problem. You don't have to divide the work up into chunks when you're threading (which you do if you're kicking the work from a timer). But of course your thread can't touch the GUI, so life can get a little complicated when you start threading. There's an intro to worker threads on my website here.
Analogy?
Take a look here for a brief explanation of callback functions:
What is a “callback” in C and how are they implemented?
Using a timer with a callback would be saying 'call function x every y seconds' and with a system that supports multitasking, that function would be called every y seconds in a second thread of execution, no matter what the original function might be doing.
Edit: As has been suggested in another answer, the system might not create a second thread for you, in which case you'd have to create the thread yourself and set up the callback from that thread.
Edit: In Windows, you can use the SetTimer function. It will post a WM_TIMER message to your window's message queue, which your message loop might handle itself or hand over to the default message procedure to call a callback function you've specified. I'm not sure what happens if you don't have a window, but give it a try.
Your question is fairly unclear, but it's probable they were suggesting you create a thread and run your function in that thread.
This can be done by subclassing a system-specific Thread class; by constructing the same class with some sort of call-back function as an argument; by creating a timer that invokes a callback function after some time limit... without a more specific question I can't give more specific advice.
Related
I have a program in C++. I want to call a function asynchronously with a configurable wait time before.
My idea of a solutions is to create a thread and in the body I would wait for the configured time and then call the needed function and then destroy the thread again.
The overhead seams very high to me, creating a separate thread. Is there a better solution (less overhead) like a timer to call the function later?
You could use your operating system.
On Windows you can use the WinAPI SetTimer, on Linux use timerfd or timer_create.
I am implementing a function in library which takes a while (up to a minute). It initialize a device. Now generally any long function should run in its own thread and report to main thread when it completes but I am not sure since this function is in library.
My dilemma is this, even if I implement this in a separate thread, another thread in the application has to wait on it. If so why not let the application run this function in that thread anyways?
I could pass queue or mailbox to the library function but I would prefer a simpler mechanism where the library can be used in VB, VC, C# or other windows platforms.
Alternatively I could pass HWND of the window and the library function can post message to it when it completes instead of signaling any event. That seems like most practical approach if I have to implement the function in its own thread. Is this reasonable?
Currently my function prototype is:
void InitDevice(HANDLE hWait)
When initialization is complete than I signal bWait. This works fine but I am not convinced I should use thread anyways when another secondary thread will have to wait on InitDevice. Should I pass HWNDinstead? That way the message will be posted to the primary thread and it will make better sense with multithreading.
In general, when I write library code, I normally try to stay away from creating threads unless it's really necessary. By creating a thread, you're forcing a particular threading model on the application. Perhaps they wish to use it from a very simplistic command-line tool where a single thread is fine. Or they could use it from a GUI tool where things must be multi-threaded.
So, instead, just give the library user understanding that a function call is a long-term blocking call, some callback mechanism to monitor the progress, and finally a way to immediately halt the operation which could be used by a multi-threaded application.
What you do want to claim is being thread safe. Use mutexes to protect data items if there are other functions they can call to affect the operation of the blocking function.
I am experience deadlock while trying to use WIN32 API from additional thread. The additional thread is needed in my application to improve Frame Rate. It actually helps, however, I get deadlocks in almost all of the system functions:
::ShowWindow
::MoveWindow
::UpdateWindow
I know that ShowWindow() for example, may be replaced with ShowWindowAsync() and it does solves the problem, however, there are no such alternatives in MoveWindow() and UpdateWindow().
Did someone experienced those problems, what is solution?
Thanks!
The term "deadlock" describes a very specific thing, two threads waiting for access to a resource that is locked by the other. There is no indication that this is what is happening in your case (or is there?), so what exactly is it that you are experiencing? Also, what exactly is it that you want to achieve with multithreading?
In any case, keep the UI in a single thread, use SendMessage() & Co to notify that thread of any events occurring in background threads. Alternatively, you can also use a timer to poll for certain state changes. That way, you are on the safe side and your application shouldn't lock up (at least not because of using the UI from different threads).
To be a bit more precise, you have to keep the message loop for a window and all its child windows in a single thread. You can create multiple windows and handle each of them from their own thread, but don't mix calls. In practice, this distinction isn't important though, because few applications create multiple windows (and no, e.g. a message box or other dialogs don't count).
All the API functions that you refer to have in common that they send(!) some message to the target window. UpdateWindow is probably the most obvious, because it needs to send WM_PAINT. Notice also that it "sends" the message and doesn't post to the queue (for UpdateWindow, the MSDN documentation calls this out explicitly, for the others it may be less obvious).
Also notice that windows have thread affinity as alluded to in some of the comments. Among other things this means that messages to that window are only ever received/dispatched on one thread. If you send a message to a window of another thread, the operating system is left with the task to determine when it should dispatch that message (i.e. call the window procedure). This (dispatching incoming sent messages) only happens during certain API calls during which it can be assumed to be safe to invoke the window procedure with a random message. The relevant times are during GetMessage and PeekMessage*.
So if your window owning thread (also called UI thread) is pumping messages normally, incoming sent messages are also quickly dispatched. From your question it seems however, that your UI thread is currently busy. If the second thread then invokes one of said functions, then it will block until the first thread provides a chance to have the sent messages dispatched.
As others have said, it is usually a good idea to keep user interface code on one dedicated UI thread (although exceptions - as always - prove the rule). And it is definitely necessary (for a good user experience) to have window owning threads be responsive to messages at all times. If your UI thread also has to wait on some synchronization objects, you may find MsgWaitForMultipleObjects helpful.
*the list might not be complete.
I want to call a function of the business class after every 2 hours.
I m not getting any way to implement same in C/C++ without using a while loop.
My problem is that i cannot use while(1) as this does not retun back the control for further execution.
Any pointer in this regards wud be helpful....:)
thnaks
Boost.Asio provides Timers.
In plain C, I would've considered using the alarm(2) or setitimer(2) functions. Alternatively, spawn a thread and do the waiting from there.
If you decide on the alarm or setitimer routes, bear in mind that you'll need to write signal handlers and may need a dispatch loop to note that it is time to do the periodic maintenance calls, as it's considered bad practise to do quite a few things from within a signal handler.
For a general solution, you could start a thread, which sends some message to the main thread after 2 hours.
For linux, you could use this:
http://linux.die.net/man/3/alarm
and then handle the SIGALRM signal
I've been playing with a DataBus-type design for a hobby project, and I ran into an issue. Back-end components need to notify the UI that something has happened. My implementation of the bus delivers the messages synchronously with respect to the sender. In other words, when you call Send(), the method blocks until all the handlers have called. (This allows callers to use stack memory management for event objects.)
However, consider the case where an event handler updates the GUI in response to an event. If the handler is called, and the message sender lives on another thread, then the handler cannot update the GUI due to Win32's GUI elements having thread affinity. More dynamic platforms such as .NET allow you to handle this by calling a special Invoke() method to move the method call (and the arguments) to the UI thread. I'm guessing they use the .NET parking window or the like for these sorts of things.
A morbid curiosity was born: can we do this in C++, even if we limit the scope of the problem? Can we make it nicer than existing solutions? I know Qt does something similar with the moveToThread() function.
By nicer, I'll mention that I'm specifically trying to avoid code of the following form:
if(! this->IsUIThread())
{
Invoke(MainWindowPresenter::OnTracksAdded, e);
return;
}
being at the top of every UI method. This dance was common in WinForms when dealing with this issue. I think this sort of concern should be isolated from the domain-specific code and a wrapper object made to deal with it.
My implementation consists of:
DeferredFunction - functor that stores the target method in a FastDelegate, and deep copies the single event argument. This is the object that is sent across thread boundaries.
UIEventHandler - responsible for dispatching a single event from the bus. When the Execute() method is called, it checks the thread ID. If it does not match the UI thread ID (set at construction time), a DeferredFunction is allocated on the heap with the instance, method, and event argument. A pointer to it is sent to the UI thread via PostThreadMessage().
Finally, a hook function for the thread's message pump is used to call the DeferredFunction and de-allocate it. Alternatively, I can use a message loop filter, since my UI framework (WTL) supports them.
Ultimately, is this a good idea? The whole message hooking thing makes me leery. The intent is certainly noble, but are there are any pitfalls I should know about? Or is there an easier way to do this?
I have been out of the Win32 game for a long time now, but the way we used to achieve this was by using PostMessage to post a windows message back to the UI thread and then handle the call from there, passing the additional info you need in wParam/lParam.
In fact I wouldn't be surprised if that is how .NET handles this in Control.Invoke.
Update: I was currios so I checked with reflector and this is what I found.
Control.Invoke calls MarshaledInvoke which does a bunch of checkes etc. but the interesting calls are to RegisterWindowMessage and PostMessage. So things have not changed that much :)
A little bit of follow-up info:
There are a few ways you can do this, each of which has advantages and disadvantages:
The easiest way is probably the QueueUserAPC() call. APCs are a bit too in-depth to explain, but the only drawback is they may run when you're not ready for them if the thread gets put into an alertable wait state accidently. Because of this, I avoided them. For short applications, this is probably OK.
The second way involves using PostThreadMessage(), as previously mentioned. This is better than QueueUserAPC() in that your callbacks aren't sensitive to the UI thread being in an alertable wait state, but using this API has the problem of your callbacks not being run at all. See Raymond Chen's discussion on this. To get around this, you need to put a hook on the thread's message queue.
The third way involves setting up an invisible, message-only window whose WndProc calls the deferred call, and using PostMessage() for your callback data. Because it is directed at a specific window, the messages won't get eaten in modal UI situations. Also, message-only windows are immune to system message broadcasts (thus preventing message ID collisions). The downside is it requires more code than the other options.