Edit 2: Problem solved, see my answer.
I am writing a C++ program that communicates with MATLAB through the Engine API. The C++ application is running on Windows 7, and interacting with MATLAB 2012b (32-bit).
I would like to make a time-consuming call to the MATLAB engine, using engEvalString, but cannot figure out how to make the call asynchronous. No callback is necessary (but would be nice if possible).
The following is a minimum example of what doesn't work.
#include <boost/thread.hpp>
extern "C" {
#include <engine.h>
}
int main()
{
Engine* eng = engOpen("");
engEvalString(eng,"x=10");
boost::thread asyncEval(&engEvalString,eng,"y=5");
boost::this_thread::sleep(boost::posix_time::seconds(10));
return 0;
}
After running this program, I switch to the MATLAB engine window and find:
» x
x =
10
» y
Undefined function or variable 'y'.
So it seems that the second call, which should set y=5, is never processed by the MATLAB engine.
The thread definitely runs, you can check this by moving the engEvalString call into a local function and launching this as the thread instead.
I'm really stumped here, and would appreciate any suggestions!
EDIT: As Shafik pointed out in his answer, the engine is not thread-safe. I don't think this should be an issue for my use case, as the calls I need to make are ~5 seconds apart, for a calculation that takes 2 seconds. The reason I cannot wait for this calculation, is that the C++ application is a "medium-hard"-real-time robot controller which should send commands at 50Hz. If this rate drops below 30Hz, the robot will assume network issues and close the connection.
So, I figured out the problem, but would love it if someone could explain why!
The following works:
#include <boost/thread.hpp>
extern "C" {
#include <engine.h>
}
void asyncEvalString()
{
Engine* eng = engOpen("");
engEvalString(eng,"y=5");
}
int main()
{
Engine* eng = engOpen("");
engEvalString(eng,"x=10");
boost::thread asyncEvalString(&asyncEvalString);
boost::this_thread::sleep(boost::posix_time::seconds(1));
engEvalString(eng,"z=15");
return 0;
}
As you can see, you need to get a new pointer to the engine in the new thread. The pointer returned in asyncEvalString is different to the original pointer returned by engOpen in the main function, however both pointers continue to operate without problem:
» x
x =
10
» y
y =
5
» z
z =
15
Finally, to tackle the problem of thread safety, a mutex could be set up around the engEvalString calls to ensure only one thread uses the engine at any one time. The asyncEvalString function could also be modified to trigger a callback function once the engEvalString function has been completed.
I would however appreciate someone explaining why the above solution works. Threads share heap allocated memory of the process, and can access memory on other threads' stacks (?), so I fail to understand why the first Engine* was suddenly invalid when used in a separate thread.
So according to this Mathworks document it is not thread safe so I doubt this will work:
http://www.mathworks.com/help/matlab/matlab_external/using-matlab-engine.html
and according to this document, engOpen forks a new process which would probably explain the rest of the behavior you are seeing:
http://www.mathworks.com/help/matlab/apiref/engopen.html
Also see, threads and forks, think twice about mixing them:
http://www.linuxprogrammingblog.com/threads-and-fork-think-twice-before-using-them
Related
This question already has answers here:
Is main() really start of a C++ program?
(12 answers)
Closed 4 years ago.
Why main() function run first of all then other functions what if we want another function run first then main function in c or c++.
Can anyone explain logic behind it.thanks.
Because that's what the Standard defines the language to use (C++ quoted here):
[basic.start.main]
A program shall contain a global function called main. Executing a program starts a main thread of execution (...) in which the main function is invoked (...)
So the compiler has to produce the binary in a way that calls main when the program is started by the operating system, or, in case of freestanding environments, when it's loaded.
Technically speaking, it doesn't have to be the first call in the resulting assembly. The compiler can insert some additional startup code (like initializing variables etc.), which can itself be grouped into functions. This is out of concern of a C++ program developer, but becomes quite important on embedded systems, where you need/want to be aware of almost every instruction executed.
A program has to start somewhere... As far as the developer is concerned that's typically main() - referred to as the "entry point".
If you want to do certain things at the beginning of your program, then just move the content of your main() into another function (like run()), and place the startup code in main() before calling run().
#include <stdio.h>
void init(void) {
/* startup */
}
void run(void) {
/* application functionality */
}
int main(void) {
init();
run();
exit 0;
}
As far as the wider system is concerned there is an amount of setup that happens first:
The process needs to be created (e.g: fork())
The stack needs to be prepared
Global variables need to be initialized
etc...
This is because you can create any number of functions in a program. You can have 1 function, 10, 2340 functions, or whatever. The program needs to know where to start. This is the purpose of the main function, as that is always the first function called.
You need to have a place in the program where the execution starts. In C it is function main.
But the program starts executing before the call to the main. That before main code prepares the execution environment for your program and it is called
a startup code.
I am developing a C++ program and it would be useful to use some function, script or something that makes the program restart. It's a big program so restarting all the variables manually will take me long time...
I do not know if there is any way to achieve this or if it is possible.
If you really need to restart the whole program (i.e. to "close" and "open" again), the "proper" way would be to have a separate program with the sole purpose of restarting your main one. AFAIK a lot of applications with auto-update feature work this way. So when you need to restart your main program, you simply call the "restarter" one, and exit.
You can use a loop in your main function:
int main()
{
while(!i_want_to_exit_now) {
// code
}
}
Or, if you want to actually restart the program, run it from a harness:
program "$#"
while [ $? -e 42 ]; do
program "$#"
done
where 42 is a return code meaning "restart, please".
Then inside the program your restart function would look like this:
void restart() {
std::exit(42);
}
On Unicies, or anywhere else you have execve and it works like the man page specifies, you can just...kill me for using atoi, because it's generally awful, except for this sort of case.
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
int main (int argc, char** argv) {
(void) argc;
printf("arg: %s\n", argv[1]);
int count = atoi(argv[1]);
if ( getchar() == 'y' ) {
++count;
char buf[20];
sprintf(buf, "%d", count);
char* newargv[3];
newargv[0] = argv[0];
newargv[1] = buf;
newargv[2] = NULL;
execve(argv[0], newargv, NULL);
}
return count;
}
Example:
$ ./res 1
arg: 1
y
arg: 2
y
arg: 3
y
arg: 4
y
arg: 5
y
arg: 6
y
arg: 7
n
7 | $
(7 was the return code).
It neither recurses nor explicitly loops -- instead, it just calls itself, replacing its own memory space with a new version of itself.
In this way, the stack will never overflow, though all previous variables will be redeclared, just like with any reinvocation -- the getchar call prevents 100% CPU utilisation.
In the case of a self-updating binary, since the entire binary (at least, on Unix-likes, I don't know about Windows) will be copied into memory at runtime, then if the file changes on disk before the execve(argv[0], ... call, the new binary found on disk, not the same old one, will be run instead.
As #CarstenS and #bishop point out in the comments, due to the unique way in which Unix was designed, open file descriptors are kept across fork/exec, and as a result in order to avoid leaking open file descriptors across calls to execve, you should either close them before execve or open them with e, FD_CLOEXEC / O_CLOEXEC in the first place -- more information can be found on Dan Walsh's blog.
This is a very OS-specific question. In Windows you can use the Application Restart API or MFC Restart Manager. In Linux you could do an exec()
However most of the time there is a better solution. You're likely better off using a loop, as suggested in other answers.
This sounds like the wrong approach, like all your state is global and so the only clear-cut method you have of resetting everything (other than to manually assign "default" values to each variable) is to restart the whole program.
Instead, your state should be held in objects (of class type, or whatever). You are then free to create and destroy these objects whenever you like. Each new object has a fresh state with "default" values.
Don't fight C++; use it!
You probably need a loop:
int main()
{
while (true)
{
//.... Program....
}
}
Every time you need to restart, call continue; within the loop, and to end your program, use break;.
When I develop realtime systems my approach is normally a "derived main()" where I write all code called from a real main(), something like:
The main.cpp program:
int main (int argc, char *argv[])
{
while (true)
{
if (programMain(argc, argv) == 1)
break;
}
}
The programmain.cpp, where all code is written:
int programMain(int argc, char *argv[])
{
// Do whatever - the main logic goes here
// When you need to restart the program, call
return 0;
// When you need to exit the program, call
return 1;
}
In that way, every time we decide to exit the program the program will be restarted.
Detail: all variables, globals and logic must be written inside programMain()- nothing inside "main()" except the restart control.
This approach works in both Linux and Windows systems.
It sounds to me like you're asking the wrong question because you don't know enough about coding to ask the right question.
What it sounds like you're asking for is how to write some code where, on a missed call, it loops back round to the initial state and restarts the whole call/location sequence. In which case you need to use a state machine. Look up what that is, and how to write one. This is a key software concept, and you should know it if your teachers were any good at their job.
As a side note, if your program takes 5s to initialise all your variables, it's still going to take 5s when you restart it. You can't shortcut that. So from that it should be clear that you don't actually want to kill and restart your program, because then you'll get exactly the behaviour you don't want. With a state machine you could have one initialisation state for cold startup where the system has only just been turned on, and a second initialisation state for a warm restart.
Oh, and 6 threads is not very many! :)
Depending on what you mean by "restarting" the program, I can see few simple solutions.
One is to embed your whole program in some "Program" class, that essentially provides some loop that has your proper program. When you need to restart the program, you call static public method "Restart" that starts the loop again.
You could also try to make system-specific call that would start your program again, and exit.
As suggested in other answer, you could create a wrapper program for this sole purpose(and check return code to know whether to quit or restart).
The other simple option is to use goto. I know that people will hate me for even mentioning it, but let's face it: we want to make simple program, not use beautiful boilerplate. Goto going back guarantees destruction, so you could create a program with a label in the beginning, and some function "Restart" that just goes back to the beginning.
Whatever option you choose, document it well, so others(or you in the future) will use one WTF less.
PS. As mentioned by alain, goto will not destroy global nor static objects, same would go for enclosing class. Therefore any approach that does not include starting new program in place of the current one should either refrain from using global/static variables, or take proper actions to re-set them(although that might be tedious, as with addition of each static/global, you need to modify the restart routine).
Simple and clean way to do this is to add a wire from an unused data pin to the RESET pin and set it low to reset! :-)
I have been writing a sudoku solver in c++ on Xcode 7. I managed to write a successful solver using a backtracking algorithm.
Now i'm trying to parallelize whatever functions inside my solver so that I can to speed up the solving algorithm. I have 3 functions that are in charge of checking if the current number trying to be inserted into the grid exists in the row, column or box. (standard sudoku rules). Since these are mutually exclusive operations I want to parallelize them.
I know it's overkill to multithread this program, but the goal is more to learn multithreading rather than speed up my solver algorithm.
This is what I've got so far.
I've included the standard c++11 thread library.
Using default Xcode 7 build settings.
The error I get says that I'm attempting to use a deleted function which pops up when I hit the "Build and Run" button on Xcode. Xcode's intellisense does not complain bout my code. I don't understand this. Please help.
#include <thread>
....
typedef uint8_t byte;
typedef uint16_t dbyte;
....
bool sudokuGame::check(byte num, byte row, byte col)
{
setBoxFlag(true);
setColFlag(true);
setRowFlag(true);
std::thread t1{&sudokuGame::checkRow, num, row};
std::thread t2{&sudokuGame::checkColumn,num,col};
std::thread t3{&sudokuGame::checkBox,num,row,col};
t1.join();
t2.join();
t3.join();
return (getBoxFlag() && getRowFlag() && getColFlag());
}
Somewhere inside "thread" where the "attempting to use a deleted function" ERROR pops up.
...
__thread_execute(tuple<_Fp, _Args...>& __t, __tuple_indices<_Indices...>)
{
__invoke(_VSTD::move(_VSTD::get<0>(__t)), _VSTD::move(_VSTD::get<_Indices>(__t))...);
}
...
My build settings looks like this
To create a thread using non-static member functions, you need to provide the instance the member function should use, the this variable inside the thread function. This is done by passing the instance as the first argument to the thread function:
std::thread t1{&sudokuGame::checkRow, this, num, row};
// ^^^^
// Note the use of `this` here
Note that you don't need to change the thread function, it's all handled by the standard library and the compiler.
Then for another problem: The thread assignments like
t1=std::thread(&sudokuGame::checkRow, num, row);
They don't make any sense. You have already created the thread objects, initialized them, and got the thread running. And because the threads are already running you can't assign to them. See e.g this reference for the overloaded thread assignment operator.
The compiler error you get is because of the first problem, that you don't pass an instance when creating the threads.
I saw a similar, but still different question to this, so just to clarify this is not a dupe of 13428881 (Calling a function in an injected DLL).
What I have at the minute:
A DLL, injected into a target process, displaying a message box and fiddling around doing math.
What I want in the future:
A DLL which can manipulate and toy with the internals of the target process.
The next step towards achieving the desired manipulation is to call a method in a remote thread within the process I'm injecting into.
Let's take an example:
I have a C++ application, which has int main, let's say it looks like this:
int PrintText(string text)
{
cout << text;
return 1;
}
int main()
{
while (true)
{
PrintText("From the DLL");
}
}
Ok, so that's lovely, my target application is currently printing some text, and it seems to be doing so very happily. It's spamming it at an unbelievable rate, but I can slow it down using threads and sleeps etc if I need to. The fact is this isn't an issue, the code here hasn't been compiled or tested, and I've no intention of using this exact code. I'm actually working with a game.
Now, let's say I create a pointer to the method, PrintText, and that I know the address of it within that process. How do I go about calling it, externally, passing in arguments?
Locally, I believe it would look something like this:
int i;
int (*PrintSomeText)(string) = PrintText;
I could then call this function using a reference, like so:
i = operation("Text to be printed", PrintSomeText);
This should, by my theory, declare an integer called i, then define a pointer to a method which returns int, takes one string as a parameter, and the pointer stores the value of the pointer which was in PrintText. (Or something of that nature).
Very nice, so I can call my own functions via pointer, that's great, cracking in fact. I've truly astonished myself with this ability, and I do now feel like superman. I'll go save some babies or something, brb.
Back, so now I want to continue a little further, and take that next step. Let's say I know that the the method is at the address 100 in the target process (decimal, I will likely do it in hexadecimal, as I'm using CheatEngine / OllyDBG to find methods in the target process, but for this example we'll stay simple).
I presume that my injected DLL gets its own space entirely, does it have any higher access to the target process? How can I find this out?
Thanks for your time,
Josh
Edit: A small note, I'm going through the C++ tutorial book, and it's proven so far to be very useful. I've noticed that I forgot to include my operation method, so apologies for that being missing. If it's required, let me know. Thanks!
Edit nr 2: I've just made some compilable code to test this out, since I wrote most of this free hand reading from the book without an IDE, and the IDE has finally configured itself, so here is the code I'm currently working with
#include "stdafx.h"
#include <iostream>
using namespace std;
int PrintText(char * Text)
{
cout << Text << endl;
return 1;
}
int _tmain(int argc, _TCHAR* argv[])
{
int (*Print)(char*) = PrintText;
char Text[] = "Hello, world!";
PrintText(Text);
int x = (*Print)("Oh my word, it really works!");
cin.get();
return 0;
}
Note I haven't yet made it run indefinitely, so yeah, please excuse that, I'll add it shortly.
Dauphic is pretty much bang on, I have full control, as wildly was I'd like, to the target process. So, here's what I'm doing to call the target processes method (for any future readers interest):
Locate the method in memory. To do this, I first disabled ASLR (Address space layout randomization), then created a pointer to my method locally within the target program, before using the iostream to dump the pointer to screen, now I know the address of the method.
Create a typedef in the dll to be injected. This is where I got kinda stuck, but I know some guys who do this quite a lot, so I've managed to get it out of them. In my case, this is how the typedef looks:
typedef int __printPrototype(char* text);
Bind the address of the method in the target application, to a reproduction of it in the injected dll:
int (*Print)(char*);
Print = (__printPrototype*)0x0041121C;
Print("I'm injecting myself into you.");
Perfect!
Thanks to dauphic and a good friend named DarkstaR.
i had once had a very simple one or two line code that would start a function with its own thread and continue running until application closed, c++ console app. lost the project it was in, and remember it was hard to find. cant find it online now. most example account for complicated multithreading situations. but i just need to open this one function in its own thread. hopefully someone knows what im talking about, or a similar solution.
eg.
start void abc in its own thread, no parameters
An example using C++11 thread support:
#include <thread>
void abc(); // function declaration
int main()
{
std::thread abcThread(abc); // starts abc() on a separate thread
....
abcThread.join(); // waits until abcThread is done.
}
If you have no C++11 support, the same is possible using boost::thread, just by replacing std::thread by boost::thread.