I'm making a dll that has to respond to an application's requests. One of the application's requirements is that a call should not take long to complete.
Say, I have a function foo(), which is called by the host application:
int foo(arg){
// some code i need to execute, say,
LengthyRoutine();
return 0;
}
Lets say, foo has to perform a task (or call a function) that is certain to take a long time. The application allows me to set a wait variable; if this variable is non-zero when foo returns, it calls foo again and again (resetting the wait variable before each call) until wait is returned 0.
What's the best approach to this?
Do I go:
int foo(arg){
if (inRoutine == TRUE) {
wait = 1;
return 0;
} else {
if (doRoutine == TRUE) {
LengthyRoutine();
return 0;
}
}
return 0;
}
This doesn't really solve the problem that LengthyRoutine is gonna take a long time to complete. Should I spawn a thread of some sort that updates inRoutine depending on whether or not it has finished its task?
Thanks..
Spawning another thread is pretty much the best way to do it, just make sure you set the result variables before you set the variable that says you're finished to avoid race conditions. If this is called often you might want to spawn a worker thread ahead of time and reuse it to avoid thread start overhead.
There is another possible solution, do part of the work each time the function is called, however this spends more time in the DLL and probably isn't optimal, as well as being more complex to implement the worker code for most algos.
If C programming, use callback - pass the callback to foo. You have to agree on the callback signature and do some housekeeping to trigger it when the work in LengthyRoutine is done.
typedef (void) callbackFunction(void);
int foo(arg, callbackFunction)
{
// some code i need to execute, say,
// register callback and return right away
// Trigger the LengthyRoutine to run after this function returns
return 0;
}
LengthyRoutine()
{
// do lenghty routine
// now inform the caller with their suppiled callback
callbackFunction();
}
Essentially Observer Pattern in C. C++ makes the work a lot easier/cleaner in my opinion
If incredible rare situation where LengthyRoutine() isn't 3rd party code and you have all the source and it's possible to split it up then you can consider using coroutines.
Related
I'm writing a library with a C (not C++) interface that contains an event loop, call it processEvents. This should be called in a loop, and invokes user-defined callbacks when something has happened. The "something" in this case is triggered by an RPC response that is received in a different thread, and added to an event queue which is consumed by processEvents on the main thread.
So from the point of view of the user of my library, the usage looks like this:
function myCallback(void *userData) {
// ...
}
int main() {
setCallback(&myCallback, NULL);
requestCallback();
while (true) {
processEvents(); /* Eventually calls myCallback, but not immediately. */
doSomeOtherStuff();
}
}
Now I want to test, using Google Test and Google Mock, that the callback is indeed called.
I've used MockFunction<void()> to intercept the actual callback; this is called by a C-style static function that casts the void *userData to a MockFunction<void()> * and calls it. This works fine.
The trouble is: the callback isn't necessarily happen on the first call of processEvents; all I know is that it happens eventually if we keep calling processEvents in a loop.
So I guess I need something like this:
while (!testing::Mock::AllExpectationsSatisfied() && !timedOut()) {
processEvents();
}
But this fictional AllExpectationsSatisfied doesn't seem to exist. The closest I can find is VerifyAndClearExpectations, but it makes the test fail immediately if the expectations aren't met on the first try (and clears them, to boot).
Of course I make this loop run for a full second or so, which would make the test green, but also make it needlessly slow.
Does anyone know a better solution?
If you are looking for efficient synchronization between threads, check out std::condition_variable. Until a next event comes in, your implementation with a while loop will keep on spinning – using up CPU resources doing nothing useful.
Instead, it would make better sense to suspend the execution of your code, freeing up processing time for other threads, until an event comes in, and then signal to the suspended thread to resume its work. Condition variables do just that. For more information, check out the docs.
Furthermore, you might be interested in looking into std::future and std::promise, which basically encapsulate the pattern of waiting for something to come asynchronously. Find more details here.
After posting the question, I thought of using a counter that is decremented by each mock function invocation. But #PetrMánek's answer gave me a better idea. I ended up doing something like this:
MockFunction<void()> myMockFunction;
// Machinery to wire callback to invoke myMockFunction...
Semaphore semaphore; // Implementation from https://stackoverflow.com/a/4793662/14637
EXPECT_CALL(myMockFunction, Call())
.WillRepeatedly(Invoke(&semaphore, &Semaphore::notify));
do {
processEvents();
} while (semaphore.try_wait());
(I'm using a semaphore rather than std::condition_variable because (1) spurious wakeups and (2) it can be used in case I expect multiple callback invocations.)
Of course this still needs an overall timeout so a failing test won't hang forever. An optional timeout could also be added to try_wait() to make this more CPU-efficient. These improvements are left as an exercise to the reader ;)
I have a third party library. This library has function named int foo(). Function is thread based and I cannot change the content of the function. (It does not belong to me.)
When I call the function, it becomes locked and does not return the value. Is there any way to kill this thread based function, when the function is locked? For example, when the function doesn't return the value within 5 seconds, I want to kill it without any memory leak.
Since its a third party library which you have no control over, you cannot portably terminate the thread that runs that code, though you can call for the native_handle and use its thread termination facilities, you will most likely introduce leaks.
Note that, threads live in the same Address space, hence a corruption or a leak from one thread affects your entire program.
The option I can think of is to spawn a new process to run that code, if after 5 seconds it doesn't complete, you can request the OS to kill it. {No memory leaks and resources are freed} :-) ...your best choice...
A possible solution, as suggested by StoryTeller, is to call foo() in a different thread, which you control. When timeout happens, you leave the thread running in the background. This means foo() continues execution, but your program can continue. This method is portable, so you don't need to write any operation system dependent code.
Leaving foo() running can have unwanted side effects, and foo() will continue to use resources in the background, so you have to test whether this works in your situation.
#include <boost/thread.hpp>
#include <ctime>
void FooWrapper(bool& hasResult, int& result){
result = foo();
hasResult = true;
}
void AnotherFunction(){
bool hasResult = false;
int result;
boost::thread(&FooWrapper, boost::ref(hasResult), boost::ref(result));
// Wait until result, or until timeout
std::time_t startTime = time(0);
while(!hasResult && time(0) < startTime + 5){
// Do nothing
}
if(!hasResult){
throw "timeout";
}
else{
// Use result
}
}
I am using boost thread here, but you can convert it to use any thread library you want.
No, there is no way to do so without memory leaks, because the thread running foo may allocate heap data, might put some private data inside values owned by your main program or some other thead.
Notice that data liveness (and virtual address space) is a whole-program property: some heap data does not belong to a (particular) thread, but to the whole process. The library could (and probably should) use smart pointers as a convention.
I have a function to calculate the value in real time
void task() {
while(true) {
...//calculate value(value will change every loop)
}
}
In the main thread, my code is as follow, i want to use the real time value which i got from task thread,
int main() {
...
while(true) {
int v = value;//value is calculated from task thread in real time
....
}
}
The main Thread will cost about 0.5s one loop, so i want to get the lastest value to update the v in next loop,How can i do this?
It's my first time to use Thread in c++,i don't know how to write the code.Can someone help me.Thanks in advance!!
Have a look at std::thread for basic threading in general. In case of an int depending on the platform, it might simply work. If you want to be sure, use an std::atomic<int>
std::atomic<int> global_value;
void task() {
while(true) {
...//calculate value(value will change every loop)
global_value.store(value);
}
}
int main() {
...
while(true) {
int v = global_value.load();
....
}
}
std::atomic<int> will make sure, that all read and write accesses are atomic.
Make the variable outside main, and above functions.
One thing you could additionally do, is make your function recursive. Then set it up in a <thread>, which if you haven't already included, then you're not close to done. A thread is a separate routine running the whole time your other tasks are running. A recursive function is one that calls itself unless one base case is reached. Then it returns. So we need to change your thread's variable, which you can do easily just by following what I said above. Thread instructions at cplusplus.com will help you more. So do try and research it. It's out there. And if you want top level help, there's books as well. You need to have the reading skills to look at code the right way. And the only way you'll learn independence is to stalk the information down and learn it. It's old school, but it'll always work.
std::thread first (task,arg);
That instances your thread, and you've called it first. So all methods are going to be referenced through first. like first.join() which will meet you back up with the thread, after you've first.detach() from it. In the case you do, you have to .join() again to destroy it. Much like a pointer. It has become independent of the program at that point, and is running in the background.
If you want to destroy it
first.~thread();
I'm trying to check when the console is closed through the close button on Windows. I read about SetConsoleCtrlHandler and I thought I'd use that, but there's some cleanup I want to do in my main function. I'll make a small example describing what I want to do for my larger program.
BOOL CtrlHandler( DWORD fdwCtrlType )
{
switch( fdwCtrlType )
{
//Cleanup exit
case CTRL_CLOSE_EVENT:
bool* programIsOn = &???; //How do I pass the address to that variable in this function?
*programIsOn = false;
return( TRUE );
default:
return FALSE;
}
}
int main(){
MyObject obj = new MyObject();
bool programIsOn = true;
//How do I pass the address of programIsOn here?
if(!SetConsoleCtrlHandler( (PHANDLER_ROUTINE) CtrlHandler, TRUE )){
cout << "Could not set CtrlHandler. Exiting." << endl;
return 0;
}
while(programIsOn){
//...
}
//CLEANUP HERE
delete obj;
return 0;
}
I want to perform cleanup when my program closes via the console close event, however if I just close the console the main function doesn't terminate and is forced to stop. I thought of passing in programIsOn's address to the CtrlHandler callback but I have no idea how to do this without using a global variable.
TL;DR: Proper handling of this control signal is complicated. Don't bother with any 'clean-up' unless it's absolutely necessary.
The system creates a new thread (see the Remarks) in your application, which is then used to execute the handler function you registered. That immediately causes a few issues and forces you in a particular design direction.
Namely, your program suddenly became multi-threaded, with all the complications that brings. Just setting a 'program should stop' (global) boolean variable to true in the handler is not going to work; this has to be done in a thread-aware manner.
Another complication this handler brings is that the moment it returns the program is terminated as per a call to ExitProcess. This means that the handler should wait for the program to finish, again in a thread-aware manner. Queue the next complication, where the OS gives you only 10 seconds to respond to the handler before the program is terminated anyway.
The biggest issue here, I think, is that all these issues force your program to be designed in a very particular way that potentially permeates every nook and cranny of your code.
It's not necessary for your program to clean up any handles, objects, locks or memory it uses: these will all be cleaned up by Windows when your program exits.
Therefore, your clean-up code should consists solely of those operations that need to happen and otherwise wouldn't happen, such as write the end of a log file, delete temporary files, etc.
In fact, it is recommended to not perform such clean-up, as it only slows down the closing of the application and can be so hard to get right in 'unexpected termination' cases; The Old New Thing has a wonderful post about it that's also relevant to this situation.
There are two general choices here for the way to handle the remaining clean-up:
The handler routine does all the clean-up, or
the main application does all the clean-up.
Number 1 has the issue that it's very hard to determine what clean-up to perform (as this depends on where the main program is currently executing) and it's doing so 'while the engine is still running'. Number 2 means that every piece of code in the the main application needs to be aware of the possibility of termination and have short-circuit code to handle such.
So if you truly must, necessarily, absolutely, perform some additional clean-up, choose method 2. Add a global variable, preferably a std::atomic<bool> if C++11 is available to you, and use that to track whether or not the program should exit. Have the handler set it to true
// Shared global variable to track forced termination.
std::atomic<bool> programShouldExit = false;
// In the console handler:
BOOL WINAPI CtrlHandler( DWORD fdwCtrlType )
{
...
programShouldExit = true;
Sleep(10000); // Sleep for 10 seconds; after this returns the program will be terminated if it hasn't already.
}
// In the main application, regular checks should be made:
if (programShouldExit.load())
{
// Short-circuit execution, such as return from function, throw exception, etc.
}
Where you can pick your favourite short-circuiting method, for instance throwing an exception and using the RAII pattern to guard resources.
In the console handler, we sleep for as long as we think we can get away with (it doesn't really matter); the hope is that the main thread will have exited by then causing the application to exit. If not, either the sleep ends, the handler returns and the application is closed, or the OS became impatient and killed the process.
Conclusion: Don't bother with clean-up. Even if there is something you prefer to have done, such as deleting temporary files, I'd recommend you don't. It's truly not worth the hassle (but that's my opinion). If you really must, then use thread-safe means to notify the main thread that it must exit. Modify all longer-running code to handle the exit status and all other code to handle the failure of the longer-running code. Exceptions and RAII can be used to make this more manageable, for instance.
And this is why I feel that it's a very poor design choice, born from legacy code. Just being able to handle an 'exit request' requires you to jump through hoops.
I am new to multi-threading. I am using c++ on unix.
In the code below, runSearch() takes a long time and I want to be able to kill the search as soon as "cancel == true". The function cancelSearch is called by another thread.
What is the best way to solve this problem?
Thanks you..
------------------This is the existing code-------------------------
struct SearchTask : public Runnable
{
bool cancel = false;
void cancelSearch()
{
cancel = true;
}
void run()
{
cancel = false;
runSearch();
if (cancel == true)
{
return;
}
//...more steps.
}
}
EDIT: To make it more clear, say runSearch() takes 10 mins to run. After 1 min, cancel==true, then I want to exit out of run() immediately rather than waiting another 9 more mins for runSearch() to complete.
You'll need to keep checking the flag throughout the search operation. Something like this:
void run()
{
cancel = false;
while (!cancel)
{
runSearch();
//do your thread stuff...
}
}
You have mentioned that you cannot modify runSearch(). With pthreads there's a pthread_setcancelstate() function, however I don't believe this is safe, especially with C++ code that expects RAII semantics.
Safe thread cancellation must be cooperative. The code that gets canceled must be aware of the cancellation and be able to clean up after itself. If the code is not designed to do this and is simply terminated then your program will probably exhibit undefined behavior.
For this reason C++'s std::thread does not offer any method of thread cancellation and instead the code must be written with explicit cancellation checks as other answers have shown.
Create a generic method that accepts a action / delegate. Have each step be something REALLY small and specific. Send the generic method a delegate / action of what you consider a "step". In the generic method detect if cancel is true and return if true. Because steps are small if it is cancelled it shouldn't take long for the thread to die.
That is the best advice I can give without any code of what the steps do.
Also note :
void run()
{
cancel = false;
runSearch();
while (!cancel)
{
//do your thread stuff...
}
}
Won't work because if what you are doing is not a iteration it will run the entire thread before checking for !cancel. Like I said if you can add more details on what the steps do it would easier to give you advice. When working with threads that you want to halt or kill, your best bet is to split your code into very small steps.
Basically you have to poll the cancel flag everywhere. There are other tricks you could use, but they are more platform-specific, like thread cancellation, or are not general enough like interrupts.
And cancel needs to be an atomic variable (like in std::atomic, or just protected it with a mutex) otherwise the compiler might just cache the value in a register and not see the update coming from another thread.
Reading the responses is right - just because you've called a blocking function in a thread doesn't mean it magically turns into a non-blocking call. The thread may not interrupt the rest of the program, but it still has to wait for the runSearch call to complete.
OK, so there are ways round this, but they're not necessarily safe to use.
You can kill a thread explicitly. On Windows you can use TerminateThread() that will kill the thread execution. Sound good right? Well, except that it is very dangerous to use - unless you know exactly what all the resources and calls are going on in the killed thread, you may find yourself with an app that refuses to work correctly next time round. If runSearch opens a DB connection for example, the TerminateThread call will not close it. Same applies to memory, loaded dlls, and all they use. Its designed for killing totally unresponsive threads so you can close a program and restart it.
Given the above, and the very strong recommendation you not use it, the next step is to call the runSearch in a external manner - if you run your blocking call in a separate process, then the process can be killed with a lot more certainty that you won't bugger everything else up. The process dies, clears up its memory, its heap, any loaded dlls, everything. So inside your thread, call CreateProcess and wait on the handle. You'll need some form on IPC (probably best not to use shared memory as it can be a nuisance to reset that when you kill the process) to transfer the results back to your main app. If you need to kill this process, call ExitProcess on it's handle (or exit in Linux)
Note that these exit calls require to be called inside the process, so you'll need to run a thread inside the process for your blocking call. You can terminate a process externally, but again, its dangerous - not nearly as dangerous as killing a thread, but you can still trip up occasionally. (use TerminateProcess or kill for this)