I am creating an application which must execute a function that takes too long (lets call it slowfunc()), which is a problem, since my application is working with a live video feed. By running this function every frame, the frame rate is severely affected.
Is there a way to run slowfunc() in the background without using threading? I don't necessarily need it to run every frame, but every time it finishes, I'd like to examine the output. The only thing I can think of right now is to split up slowfunc() into several "mini-functions" which would each take approximately an equal amount of time, then run one minifunction per frame. However, slowfunc() is a relatively complex function, and I feel that there should be (hopefully is) a way to do this simply.
EDIT: I can't use threading because this program will eventually be used on a tiny robot processor which probably will not support threading. I guess I can use "cooperative multitasking". Thanks for your help!
Run it in a thread and after the calculation is finished, make the thread sleep until another calculation is ready to be run. That way you are not hit with the initialization of the thread every time.
You're asking for simaltaneous execution. The two ways to do this are -:
a) Multi-threading -: Create another thread to run on a background.
b) MUlti-processing -: Create another process . Take all inputs required for the function via a shared memory model. Create a synchronisation mechanism with original process(parent process). Execute this function.
It is normally prefered to use the 1st one. Faster execution.
The 2nd one guarantees that if the function crashes your parent process still runs. Although, that is a bit irrelevant since, why would you want your child(function) to crash. This needs more memory.
Related
I want to test my idea, wherein I execute some code in the context of another process at some interval. What API call or kernel functionality or l technique should I look into to execute code in another process at some interval?
Seems like I need to halt the process and modify the instruction pointer value before continuing it, if that’s remotely possible. Alternatively, I could hook into the kernel code which schedules time on the CPU for each process, and run the code each time the next time slot happens for a process. But PatchGuard probably prevents that.
This time interval doesn’t need to be precise.
The wording of the question tells me you're fairly new to programming. A remote process doesn't have AN instruction pointer, it typically has many - one per executing thread. That's why the normal approach would be to not mess with any of those instruction pointers. Instead, you create a new thread in the remote process CreateRemoteThreadEx.
Since this thread is under your control, it can just run an infinite loop alternating between Sleep and the function you want to call.
I have a question concerning long calculations:
While executing some tasks of my GUI long calculations might be done. This is not a problem, it just takes a while – everything works fine (at least the results are fine).
What bothers me is that after a certain time my GUI doesn't seem to respond: For example my ProcessBar that is shown during calculations will not be displayed and in the title bar of my GUI the text “keine Rückmeldung” is added (which means something like busy, crashed, etc - sorry I don't know the correct translation which makes it hard for me to find anything in the internet about that issue).
Is there a possibility to stop that behavior?
Thank you.
You should outsource your expensive, long-lasting calculations from the GUI-Thread to a worker thread to prevent your GUI from freezing.
Qt-Documentation: Threading Basics
Good explanation of QThread-usage I found useful: How To Really, Truly Use QThreads
The GUI itself cannot be changed from a worker thread. You have to notify your main-thread about a data-change and update your GUI from there.
You have two options. The more efficient one is to put your calculations into another thread (or multiple threads, there are very few single core CPUs in modern PCs). JSilver's answer has a few links for you.
However, with threads come multitude of threading related things you must learn and take into account. There's a lot of potential for subtle bugs, if you don't know what you're doing. So I would recommend alternative approach as first step, single-threaded. As a bonus, it'll make moving to multi-threaded solution much easier later.
Create a plain sublclass of QObject. Into this QObject, put the state of your calculation as member variables.
Write a slot method into above class, which does a small piece of the calculation, then returns. It should do it's thing at most around 50 ms for good user experience. You can just use a fixed number of iterations in your loop, or use QElapsedTimer to measure time, or whatever. And then, when called again, the method should continue the calculation again for another 50ms. When calculation completes, the method can for example emit a signal with the results.
Add a QTimer with interval 0. Connect the timeout to the slot method described above. Interval 0 here effectively means, Qt will call the method as often as it can. You want this, because you want the calculation to finish as quickly as possible of course. However, since the method returns very soon, then Qt can do other stuff (update GUI etc), before calling your method again.
Once this works, in single thread, you can then learn to do Qt threading and move the worker object to live in another thread, for potentially increased performance. Also then you will have a single-threaded baseline version to compare to, in case you run into threading problems.
I have made a program in c++ for changing the password of a system and I wanna run it for every 2 hours,then I end up with two choice in c++ ,one is Sleep(ms) and the other is using recent thread lib this_thread::sleep_for(2h)[ 2h using std::chrono_literals].
The doubt I have been wandering is, does long pausing an exe will work the way we want, is it any other better way than what i mentioned?
I have also planned to put my exe as a windows service.
any other better way than what i mentioned?
Yes.
I suggest, that you do not pause the program at. Simply do the thing, and exit.
Extract the scheduling part to a separate program. You don't even need to write this scheduler, because it already exists on most operating systems.
If you have some task that must be run periodically with long periods of waiting, you should use a program or script, that does the task and exits, and a scheduler, which handles the waiting. There're also questions you need to consider, for example:
do you need to start your task if the scheduled time was missed (due to reboot, for example)
do you allow several of your tasks to run at once, if time it takes to complete is longer than wait period
What you're trying to do is to implement a scheduler yourself. If this is what you want, then sleep is a posix function, and chrono::thread::sleep_for is cross-platform, so it's better to use the second one.
However, it's not generally recommended to implement schedulers, moreover, so simple ones.
I have a program which executes constantly and I need to save data every minute.
The program process data and every minute I want to save the value of a variable and do some statistical operations to know the variation of this variable.
I thought i can make it with a signal, SIGALRM and alarm(60). My subquestion is, can I put a class method as the destiny method for SIGALRM?
Any other idea to execute a method to save data and do some operations every minute ??
The program is written in C++, runs in Linux an a mono-core processor.
Your solution using alarm will work, both open and write being asynchronous-signal-safe. Though you have to be aware that interactions between alarm and sleep are undefined, so don't use them in the same program.
A different solution, especially in case you already use an epoll, would be to have a timerfd trigger the epoll. That will avoid possible undefined interactions.
As for the actual saving, consider forking. This is a technique that I learned from redis (maybe someone else invented it, but that's where I learned it from), and which I consider totally cool. The point being that the forked process can take all time in the universe to finish writing as much data as you want to disk. It can access the snapshot at the time of forking while the other process keeps running and modifying data. And thanks to page magic done in the kernel, it still all works seamlessly without any risk of corruption, without ever stalling, and without ever needing to look at something like asynchronous IO, which is great.
You can call a class method using something like boost bind
Apart from that I wouldn't recommend to use signals for that, they are not that reliable, and could, for example, make one of your syscalls to return prematurely.
I would spawn a thread, assuming your monocore doesn't mean no threads, that waits 60 seconds, takes locks, makes calcs, outputs and releases locks.
As they have already suggested, if you have an async compatible system(driven by events) you could use timerfd to generate events.
Saving data from a signal handler is a very bad idea. Even if open and write are async-signal-safe, your data could very well be in an inconsistent state due to a signal interrupting a function that was modifying it.
A much better approach would be to add to all functions which modify the data:
if (current_time > last_save_time + 60) save();
This will avoid useless saves when the data has not been modified, too. If you don't want the overhead of making a system call to determine the current time on every operation, you could instead install a timer/signal handler that updates current_time, as long as you declare it volatile.
Another good approach would be to use threads instead of signals. Then you should use a mutex (or better, rwlock) to synchronize access to the data.
I'm looking for a way to restart a thread, either from inside that thread's context or from outside the thread, possibly from within another process. (Any of these options will work.) I am aware of the difficulty of hibernating entire processes, and I'm pretty sure that those same difficulties attend to threads. However, I'm asking anyway in the hopes that someone has some insight.
My goal is to pause, save to file, and restart a running thread from its exact context with no modification to that thread's code, or rather, modification in only a small area - i.e., I can't go writing serialization functions throughout the code. The main block of code must be unmodified, and will not have any global/system handles (file handles, sockets, mutexes, etc.) Really down-and-dirty details like CPU registers do not need to be saved; but basically the heap, stack, and program counter should be saved, and anything else required to get the thread running again logically correctly from its save point. The resulting state of the program should be no different, if it was saved or not.
This is for a debugging program for high-reliability software; the goal is to run simulations of the software with various scripts for input, and be able to pause a running simulation and then restart it again later - or get the sim to a branch point, save it, make lots of copies and then run further simulations from the common starting point. This is why the main program cannot be modified.
The main thread language is in C++, and should run on Windows and Linux, however if there is a way to only do this on one system, then that's acceptable too.
Thanks in advance.
I think what you're asking is much more complicated than you think. I am not too familiar with Windows programming but here are some of the difficulties you'll face in Linux.
A saved thread can only be restored from the root process that originally spawned the thread, otherwise the dynamic libraries would be broken. Because of this saving to disk is essentially meaningless. The reason is dynamic libraries are loaded at different address each time they're loaded. The only way around this would be to take complete control of dynamically linking, no small feat. It's possible, but pretty scary.
The suspended thread will have variables in the the heap. You'd need to be able to find all globals 'owned' by the thread. The 'owned' state of any piece of the heap cannot be determined. In the future it may be possible with the C++0x's garbage collection ABI. You can't just assume the whole stack belongs to the thread to be paused. The main thread uses the heap when creating threads. So blowing away the heap when deserializing the paused thread would break the main thread.
You need to address the issues with globals. And not just the globals from created in the threads. Globals (or statics) can and often are created in dynamic libraries.
There are more resources to a program than just memory. You have file handles, network sockets, database connections, etc. A file handle is just a number. serializing its memory is completely meaningless without the context of the process the file was opened in.
All that said. I don't think the core problem is impossible, just that you should consider a different approach.
Anyway to try to implement this the thread to paused needs to be in a known state. I imagine the thread to be stoped would call a library function meant the halt the process so it could be resumed.
I think the linux system call fork is your friend. Fork perfectly duplicates a process. Have the system run to the desired point and fork. One fork wait to fork others. The second fork runs one set of input.
once it completes the first fork can for again. Again the second fork can run another set of input.
continue ad infinitum.
Threads run in the context of a process. So if you want to do anything like persist a thread state to disk, you need to "hibernate" the entire process.
You will need to serialise the entire set of the processes data. And you'll need to store the current thread execution point. I think serialising the process is do-able (check out boost::serialize) but the thread stop point is a lot more difficult. I would put places where it can be stopped through the code, but as you say, you cannot modify the code.
Given that problem, you're looking at virtualising the platform the app is running on, and using its suspend functionality to pause the entire thing. You might find more information about how to do this in the virtualisation vendor's features, eg Xen.
As the whole logical address space of the program is part of the thread's context, you would have to hibernate the whole process.
If you can guarantee that the thread only uses local variables, you could save its stack. It is easy to suspend a thread with pthreads, but I don't see how you could access its stack from outside then.
The way you would have to do this is via VM Snapshots; get a copy of VMWare Workstation, then you can write code to automate starting/stopping/snapshotting the machine at different points. Any other approach is pretty untenable, as while you might be able to freeze and dethaw a process, you can't reconstruct the system state it expects (all the stuff that Caspin mentions like file handles et al.)