I have looked throughfully around but could not find any reference to this problem.
I wrote a c++ program that I am testing with boost/unit. The serial version works fine and the unit test is working.
Now I have made the program parallel via a function doing embarrassingly parallel work with MPI. If a write down my own test calling the parallel function -- let's call it parafunction -- it is working well, MPI runs all right.
Compilation is done with mpic++ and I use mpixec to run the program.
If I call parafunction in boost test case however, the MPI goes all wrong, the test are launched multiple time and the process crash when several MPI::Init are called.
Here is an example of the error I get :
The MPI_comm_size() function was called after MPI_FINALIZE was invoked.
This is disallowed by the MPI standard.
Your MPI job will now abort.
My test case is on a test_unit, automatically handled by a master_test_suite. As I said without the parallelisation it works perfectly well.
Parafunction calls MPI::Init and MPI::Finalize, and no other function of files is supposed to do any MPI related stuff.
Has anyone ever encountered a similar problem before ?
My test run are quite long therefore I could really use the parallel version of my program !
Thanks for your help
A function, which both initialises and then finalises can only be called once, because MPI can be only initialised once during the lifetime of the program and can only be finalised once. To prevent multiple initialisation calls, put the call to MPI_Init() or MPI_Init_thread() in a conditional:
int already_initialised;
MPI_Initialized(&already_initialised);
if (!already_initialised)
MPI_Init(NULL, NULL);
As for the finalisation, it should be moved outside of your function, probably in an atexit(3) handler if you don't want to pollute the outer scope with MPI calls. For example:
void finalise_mpi(void)
{
int already_finalised;
MPI_Finalized(&already_finalised);
if (!already_finalised)
MPI_Finalize();
}
...
atexit(finalise_mpi);
...
The atexit() call could be part of the initialisation code, e.g.:
int already_initialised;
MPI_Initialized(&already_initialised);
if (!already_initialised)
{
MPI_Init(NULL, NULL);
atexit(finalise_mpi);
}
This would not install the atexit(3) handler if MPI was already initialised. The basic idea is that if MPI was initialised on entry to the function, then it would mean that MPI_Init() was called in the outer scope and one would normally expect that MPI_Finalize() is also called there.
If I were you, I would move MPI initialisation and finalisation out of the parallel processing function. The proper calling sequence would be to initialise MPI, run the tests, then finalise MPI.
I've used the C bindings in the above text as the C++ bindings were deprecated in MPI-2.2 and then deleted in MPI-3.0.
Related
I have a Fortran code which is predominantly used for running large MPI calculations, but occasionally I want to run it on a machine which does not have MPI available for quick data processing tasks.
I have a logical variable which determines whether or not the program is being run in MPI mode or not, and when it is false the code will not call any MPI subroutines. The way I determine whether or not to run in MPI mode at the moment is by testing to see if a dummy file "NO_MPI" exists which I dislike due to its inelegance and the fact that I usually forget that I need to create this file when running in a non-MPI environment.
When the code is run in a non-MPI environment the MPI_init subroutine will fail and cause the program to crash. So what I would like to do is call it with the optional error output:
call MPI_init(ierr)
and then if an error is returned continue with the node in non-MPI mode.
The issue is that the default MPI error handler will abort the program without returning an error. For any other MPI subroutine the solution would be:
call MPI_Comm_set_errhandler(MPI_COMM_WORLD, MPI_ERRORS_RETURN)
to tell MPI not to abort and return the error code. However I cannot call this subroutine before MPI_init without getting the error
Attempting to use an MPI routine before initializing MPICH.
Is there any way to change the default error handler before calling MPI_init, perhaps specifying it with a compiler flag? I am using the IFORT compiler with MPICH.
I feel that there must be some way of testing the error code from MPI_init, otherwise what is the point of allowing MPI_init to accept the optional error return as an argument when the default behaviour is to abort without returning errors?
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.
As a newbie to c++, coming from python, I'm not sure why c++ doesn't allow statements outside of a function (in the global namespace?). It seems like this could be useful to do some initialization before main() is called or other functions are even declared. (I'm not trying to argue with the compiler, I'd just like to know the thought process behind implementing it this way.)
When you're running a python program, the interpreter runs through it from top to bottom executing as it goes. In C++, that doesn't happen. The compiler builds all your functions into little blobs of machine code and then the linker hooks them up. At runtime, the operating system calls your main function, and everything goes on from there. In that context, code outside of functions is meaningless - when would it run?
This can be thought of as a style difference between C++ and Python. However, there are pretty good reasons for it too. In C and C++, there is a very clear and specific place that the execution of your code starts from, and that's the beginning of the main() function (of course, this is only an approximation of the truth, but we can ignore that for now.) Actually, a C/C++ program starts and ends with the main() function which - in my opinion - helps quite a lot when you want to understand what a program actually does. The high-level flow of the program is clearer. Contrast this with the alternative; with code scattered all through the file and in between functions and whatnot.
Even in a well-organized and non-trivial Python program, you put your main body of code under an if __name__ == "__main__":, don't you?
Now for some stuff that are a little bit more advanced. There are ways for code to run before the main() function is called. Here's one of them:
#include <iostream>
using namespace std;
bool RunBeforeMain ()
{
cout << "Before main()!" << endl;
return true;
}
// This variable here causes the above function to be called
bool ignore_this_variable = RunBeforeMain ();
int main ()
{
cout << "Start of main()" << endl;
return 0;
}
Also, the constructors of all the global variables and all the static members of classes and some platform-dependent stuff are run before main(). Analogously, there are ways for code to run after the main() is finished. Those are usually the destructors for objects constructed before main() began, and functions registered with the atexit() function.
The main() is the access point to the program. So any code you wanna write would be needs to have an order of execution from that point.
Static variables are initiated before the main() is executed, so you can initiate whatever variables you need before that.
But if you want run code that initiates the state of the program, you should do it just in the beginning of the program, and abuse the static variables and do it some constructor.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Does the program execution always start from main in C?
i want to start the execution of my program which contains 2 functions (excluding main)
void check(void)
void execute(void)
i want to start my execution from check(), is it possible in c/c++?
You can do this with a simple wrapper:
int main()
{
check();
}
You can't portably do it in any other way since the standard explicitly specifies main as the program entry point.
EDIT for comment: Don't ever do this. In C++ you could abuse static initialization to have check called before main during static init, but you still can't call main legally from check. You can just have check run first. As noted in a comment this doesn't work in C because it requires constant initializers.
// At file scope.
bool abuse_the_language = (check(), true);
int main()
{
// No op if desired.
}
Various linkers have various options to specify the entry point. Eg. Microsoft linker uses /ENTRY:function:
The /ENTRY option specifies an entry point function as the starting
address for an .exe file or DLL.
GNU's ld uses the -e or ENTRY() in the command file.
Needles to say, modifying the entry point is a very advanced feature which you must absolutely understand how it works. For one, it may cause skipping the loading the standard libraries initialization.
int main()
{
check();
return 0;
}
Calling check from main seems like the most logical solution, but you could still explore using /ENTRY to define another entry point for your application. See here for more info.
You cannot start in something other than main, although there are ways to have some code execute before main.
Putting code in a static initialization block will have the code run prior to main; however, it won't be 100% controllable. while you can be assured it runs prior to main, you cannot specify the order that two static initialization blocks will run prior to them both executing before main.
Linkers and loaders both have the concept of main held as a shared "understood" start of a C / C++ program; however, there is code that runs prior to main. This code is responsible for "setting up the environment" of the program (things like setting up stdin or cin). By putting code in a static initialization block, you effectively say, "hey you need to do this too to have the right environment". Generally, this should be something small, that can stand independently in execution order of other items.
If you need two or three things to execute in order before main, then make them into proper functions and call them at the beginning of main.
There is a contrived way to achieve that, but it is nothing more than a hack.
The idea is to create a static library containing the main function, and make it call your "check" function.
The linker will resolve the symbol when linking against your "program", and your "program" code will indeed not have a main by itself.
This is NOT recommended, unless you have very specific needs (an example that pops to mind is Windows Screensavers, as the helper library that comes with the Windows SDK has a main function that performs specific initialization like parsing the command line).
It may be supportted by the compiler. For example, gcc, you can use -nostartfiles and --entry=xxx to set the entry point of the program. The default entry point is _start, which will call the function main.
You can "intercept" the call to main by creating an object before the main starts. The constructor needs to execute your function.
#include <iostream>
void foo()
{
// do stuff
std::cout<<"exiting from foo" <<std::endl;
}
struct A
{
A(){ foo(); };
};
static A a;
int main()
{
// something
std::cout<<"starting main()" <<std::endl;
}
I have found solution to my own question.
we can simply use
#pragma startup function-name <priority>
#pragma exit function-name <priority>
These two pragmas allow the program to specify function(s) that should be called either upon program startup (before the main function is called), or program exit (just before the program terminates through _exit).
The specified function-name must be a previously declared function taking no arguments and returning void; in other words, it should be declared as:
void func(void);
The optional priority parameter should be an integer in the range 64 to 255. The highest priority is 0. Functions with higher priorities are called first at startup and last at exit. If you don't specify a priority, it defaults to 100.
thanks!
I deployed a MATLAB project into a DLL, to be called from C++, and it works just fine. Happy days.
But what happens when the user asks to cancel an operation?
I tried creating a global variable named UserAborted. I initialize it to 0 before running the long function in MATLAB. I also wrote the following two functions:
function AbortIfUserRequested
global UserAborted
if (UserAborted == 1)
error('User Abort');
end
end
function UserAbortLongFunction
global UserAborted
UserAborted = 1;
end
I call upon AbortIfUserRequested in every iteration of the loop in my long function. I also exported UserAbortLongFunction.
I expected that pretty soon after called UserAbortLongFunction, the long function would reach a call to AbortIfUserRequested, and throw an error.
Instead, the long function keeps running until the end, and only then does the value of UserAborted get changed.
All I want to do is abort that long function when the user asks me to! Is there any way to do that?
Try calling the DRAWNOW function in AbortIfUserRequested. Although Matlab is single-threaded (from an API perspective), it does allow for interrupts. I've had success by calling this function with pure M-code where user input (like Ctrl-C) otherwise gets locked out.
Matlab needs to provide callback functions to show execution progress and possibly halt it. A Google search shows lots of people wanting this but no implementation from Mathworks.
Matlab's single-threaded nature might be preventing the update to the global variable's value from propagating while the first function is executing. You could try sticking the abort flag in a Java object, like a HashMap, for a layer of indirection. Since Java objects are passed by reference, an update to its state may be visible immediately, without requiring a change to the Matlab variable itself.
Here's a snippet to do so. (Sorry, I don't have a Matlab Compiler license to test this out in a deployed DLL.)
function AbortIfUserRequested
global SharedState
if SharedState.get('UserAborted')
error('User Abort');
end
end
function UserAbortLongFunction
global SharedState
SharedState.put('UserAborted', 1);
end
function InitUserAbort
global SharedState
SharedState = java.util.Collections.synchronizedMap(java.util.HashMap());
SharedState.put('UserAborted', 0);
end
Matlab app data is also effectively passed by reference. Putting the abort flag in appdata instead of a global variable might work, too. If your library works with a Matlab GUI, you can put the app data on its figure handle instead of the global handle 0. This would be more idiomatic Matlab than the Java object, if it works.
function AbortIfUserRequested
if getappdata(0, 'UserAborted')
error('User Abort');
end
end
function UserAbortLongFunction
setappdata(0, 'UserAborted', 1);
end