I have a certain Fortran program which is parallelized using MPI. For a certain application I know want to run 2 fairly (but not absolutely) identical instances of this program. These 2 concurrently running programs would have to communicate with each other during runtime.
I thought one of the easiest ways to do this would be to define a global communicator (eg. MPI_COMM_WORLD_GLOBAL) which spans all the processes. I would then proceed to redefine the usual global communicator MPI_COMM_WORLD to be the total amount of processes used by this instance of the program (note that, although I talk of multiple instances of the program, there would only be 1 real program running in this case).
I would like to keep MPI_COMM_WORLD to be the total amount of processes used for 'this' instance of the program, as to avoid changing the communicators throughout my code.
My question is therefore, is there a straightforward way of redefining MPI_COMM_WORLD in Fortran? Or is my proposed approach bad practice and should I look into other methods.
Thanks in advance.
It sounds like you might be thinking of things (or maybe just describing them) in the wrong way. If you run two separate instances of your application (calling mpiexec/mpirun twice), your two applications won't be able to talk to each other without doing some extra work (MPI_COMM_CONNECT/MPI_COMM_ACCEPT). If, in fact, you will run both instances of your application using the same launcher (calling mpiexec/mpirun one time), then you should just divide your communicator in half at the beginning of your code by calling something like MPI_COMM_SPLIT. This will give you a different communicator for each half of the application and you can just use that communicator for your local (within one half of your application) communication and use MPI_COMM_WORLD when you need to do global communication.
This is the entire idea of MPI in the first place. You should use different communicators to create different communication spaces within your application. Everything shouldn't be done on MPI_COMM_WORLD.
What you can do is have one copy of the MPI application spawn the other using MPI_COMM_SPAWN. When doing so, MPI_COMM_WORLD in each application will only encompass the processes in that particular application, i.e. there will be two separate MPI_COMM_WORLD's - one for the parent job and one for the child one. The two copies will then be able to communicate via the established intercommunicator. The parent job receives the intercommunicator in the output parameter of MPI_COMM_SPAWN while the child job can obtain it by calling MPI_COMM_GET_PARENT.
Intercommunicators differ somewhat from the regular intracommunicators (such as MPI_COMM_WORLD). They are asymmetric in the sense that there are local and remote groups of processes in them and local operations are not possible. It is possible to convert an intercommunicator into an intracommunicator using MPI_INTERCOMM_MERGE.
The relevant logic in your case would be:
First copy
INTEGER, PARAMETER :: nprocs = 32
INTEGER :: child_intercomm, supercomm, ierr
INTEGER, DIMENSION(nprocs) :: error_codes
CHARACTER(LEN=40) :: command
! Spawn the second copy with nprocs MPI processes
command = './program2'
CALL MPI_COMM_SPAWN(command, MPI_ARGV_NULL, nprocs, MPI_INFO_NULL, 0, &
child_intercomm, error_codes, ierr)
CALL MPI_INTERCOMM_MERGE(child_intercomm, .FALSE., supercomm, ierr)
Second (spawned) copy
INTEGER :: parent_intercomm, supercomm, ierr
CALL MPI_COMM_GET_PARENT(parent_intercomm, ierr)
CALL MPI_INTERCOMM_MERGE(parent_intercomm, .TRUE., supercomm, ierr)
The code is a bit asymmetric in the sense that there is a parent that spawns another copy and that requires a bit of different logic in both programs. You can still call MPI_COMM_GET_PARENT in the parent and it will simply return MPI_COMM_NULL. That way your program will get to know that it is the first copy and do the spawn.
You can also name supercomm MPI_COMM_WORLD_GLOBAL instead, but you should notice that the MPI_ name prefix is reserved for MPI calls and constants and you should not use it for your own variables.
MPI_COMM_WORLD can be just a constant or a macro. Trying to redefine it is asking for trouble.
In my OpenMPI it is a parameter with value 9.
You would have to make your own variable with that name which shadows that one from module mpi or mpif.h, e.g., by using some custom module or include file.
It shouldn't be that difficult to refactor your code to use a variable for a communicator instead of the hard-coded MPI_COMM_WORLD using some modern text editor or IDE. With some tools it can be as simple as one global Search and Replace and declaration and definition of the constant (in a module).
Related
I want to use the same lua file for multiple game objects
The lua file:
function onUpdate()
if Input.isKeyDown(Keys.d) then
actor.x = actor.x + 0.1
end
if Input.isKeyDown(Keys.a) then
actor.x = actor.x - 0.1
end
if Input.isKeyDown(Keys.w) then
actor.y = actor.y + 0.1
end
if Input.isKeyDown(Keys.s) then
actor.y = actor.y - 0.1
end
end
Question
Is it a good practice to have a Lua State for each object or should i use the same state for the same file and update the "actor" global variable before the game object calls the script
(I want to avoid using tables because i would have to use the table name before the variables and function calls)
(I don't know if there is any other solution... I am new to lua)
While it is nice that you can have many Lua states within a single program, keep in mind that each of them does take up some memory. If there's a good reason why you should keep two environments completely separate, like security concearns, or totally unrelated subsystems that may or may not be needed at the same time, then it's certainly worth it.
Otherwise, it's usually better and more manageable to have a single Lua state.
If you need strong separation between different blocks of logic, Lua has you covered:
Coroutines
If you need to have several blocks of logic that you want to pause and resume later on, you can simply wrap them up in coroutines. This can easily be done from C as well, and allows you to do most of what you could do with different Lua states.
Environments
While these work somewhat differently before and after Lua 5.2, the basic idea is the same: you can change what "global" variables are visible to a section of your code, even using metatables to access other data or generate it on the fly.
With those two, you should really not have much need for separate Lua states in a game. One exception to this rule would obviously be multi-threading; you shouldn't have more than one thread with access to the same Lua state unless you use some sort of locking mechanism, so it would make sense to have one state per thread and set up a way for them to communicate from within C.
I'm pulling my hairs out (that I don't have) on a big problem, but probably simple one.
I'm developing a Server application in QT.
This server will accept TCP connections and dialog with specific and proprietary Ethernet products.
Each time a product is called on this server, a new thread is created with this new TCP connection and a dialog begins with some "common" requests.
At a certain step of this dialog, the thread needs to run a Lua script to continue the process: not with a common procedure - but a specific one for each product.
This is my problem:
When I run the Lua script, I need to use methods of the Thread class (the current thread). Due to the Extern "C" declaration of C fonctions that can be used in Lua scripts I can't call the methods of my current thread, because I don't see how to program (or the principle behind) the structure of this exchange:
- the thread have N methods to send data on IP depending of the protocol (we will call this methods mythread::CClass_fn_X())
- the registered function C for Lua will be call LUA_FN_X(). This is just a gateway to call CClass_fn_X() with computed parameters from Lua)
if in LUA_FN_X() I want to do a "this->CClass_fn_X()", I can't because C LUA function have no reference to "this" of the thread.
I've tried various things the past few days and I can't find a good solution (or simply any solution) for my problem.
Please help me, I'm not requiring code, but just the principle to do that.
Also, is the Lua interpreter thread safe? Can I run separately Lua scripts in different threads?
To answer your last question, Lua is not OS-thread safe if you use the same Lua state in different OS threads, but you can safely run different Lua states in different OS threads.
Do not confuse OS threads with Lua threads, which are coroutines and run in the same state.
There are several ways to do this. If you only have one non-main thread that can call your Lua script, then your script just needs to know the thread object it belongs to and provide that as parameter when it calls into the C++. There are many strategies that can work there, but one is that you create a global variable that is a light userdata for your thread (basically a pointer or handle that is sufficient to identify thread). Then when you call your script, the script calls your C function with that light userdata: your C function must assume the userdata received is actually the pointer or handle or integer (whatever your strategy) for thread so then it can find the right Thread instance and call the appropriate method. For example, the C++ side:
// tell Lua which thread:
lua_pushlightuserdata(L, threadHandle); // threadHandle uniquely identifies thread
lua_setglobal(L, "scriptThread");
// call script:
// assumes you loaded script before and saved the compiled chunk
// as global variable "script" (other SO question shows how to do it)
lua_getglobal(L, "script");
lua_pcall(L, 0, 0, 0);
and the Lua script:
-- call C++ func:
LUA_FN_X(scriptThread);
and the C/C++ wrapper function that you registered in Lua state as LUA_FN_X:
void cwrapper(lua_State* L)
{
Thread* thread = (Thread*)lua_touserdata(L, -1);
thread->CClass_fn_X();
}
The Lua can't do much with a light userdata except pass it back to C++. If you want to query various thread methods, and there you have several thread instances that can call the Lua script, it might be worthwhile using a full userdata.
I want to use multi-processes in a function and how can I make it.
As you know, MPI_Init needs two parameter: "int argc, char **argv". Does it mean that I must add these two parameters in the function definition?
My requirement is that I want to parallelize a step in function in stead of the step in main program.
For example,
func(mat &A, vec &x) {
some computation on A;
auto B = sub_mat(A, 0, 10);
B*x; // I want to parallelize this computation
}
main(){
mat A;
vec x;
func(A, x);
}
I just want to use MPI in B*x, but I don't know how to init MPI? By the way, if I can init MPI int func, does A exist in every processes at this time?
Help me & thanks!
You do not need to pass argc and argv around since MPI-2 lifted the restriction in MPI-1 that compilant implementations may require arguments to MPI_Init to be the same as the arguments to main:
In MPI-2 implementations are not allowed to impose this requirement. Conforming implementations of MPI are required to allow applications to pass NULL for both the argc and argv arguments of main.
But you still have to test if MPI is already initialised since MPI_Init() (or MPI_Init_thread()) should be called no more than once. This is done using MPI_Initialized(), so your code should look like this:
int initialized, finalized;
MPI_Initialized(&initialized);
if (!initialized)
MPI_Init(NULL, NULL);
// Perform work in parallel
...
// You also need this when your program is about to exit
MPI_Finalized(&finalized);
if (!finalized)
MPI_Finalize();
Note that MPI can be initialised and then finalised only once for the entire lifetime of the application. That is surrounding a block of function code with MPI_Init() ... MPI_Finalize() won't work if the function is to be called multiple times, i.e. MPI doesn't function the same way as OpenMP with its parallel regions does.
By the way, if I can init MPI int func, does A exist in every processes at this time?
A running MPI program consists of multiple processes with their own private address spaces. Usually these are multiple copies of the same program code (the so-called Single Program Multiple Data or SPMD paradigm), but could also be multiple copies of several programs, written to work together (also called Multiple Programs Multiple Data or MPMD). SPMD is the more simple and more common case where all processes execute exactly the same code up to the point where their MPI rank is used to branch the execution into multiple directions. So yes, A exists in every process and if no (pseudo-)random numbers/events are involved in the preceding computations, then A would have the same value in every MPI process prior to the initialisation of the MPI library. Note that MPI_Init() is just a regular library call as any other library call. It doesn't change the content of user memory - it only makes the multitude of running MPI processes aware of one another and enables them to communicate with each other, thus enabling them to work collectively in order to solve the particular problem.
If you want to use MPI_Init in a subfunction, you have to pass int argc, char **argv to the function, in order to pass it on.
But even if you just want to parallelise a part of a subfunction, you can (and should for more transparent code) use MPI_Init early in the programm. E.g. after other initialisation stuff is finished, or if you want to use it close to your parallelised function, immediately before you call the function.
In principle the function does not have to know about argc and argv, does it?
I have been looking for a way to dynamically load functions into c++ for some time now, and I think I have finally figure it out. Here is the plan:
Pass the function as a string into C++ (via a socket connection, a file, or something).
Write the string into file.
Have the C++ program compile the file and execute it. If there are any errors, catch them and return it.
Have the newly executed program with the new function pass the memory location of the function to the currently running program.
Save the location of the function to a function pointer variable (the function will always have the same return type and arguments, so
this simplifies the declaration of the pointer).
Run the new function with the function pointer.
The issue is that after step 4, I do not want to keep the new program running since if I do this very often, many running programs will suck up threads. Is there some way to close the new program, but preserve the memory location where the new function is stored? I do not want it being overwritten or made available to other programs while it is still in use.
If you guys have any suggestions for the other steps as well, that would be appreciated as well. There might be other libraries that do things similar to this, and it is fine to recommend them, but this is the approach I want to look into — if not for the accomplishment of it, then for the knowledge of knowing how to do so.
Edit: I am aware of dynamically linked libraries. This is something I am largely looking into to gain a better understanding of how things work in C++.
I can't see how this can work. When you run the new program it'll be a separate process and so any addresses in its process space have no meaning in the original process.
And not just that, but the code you want to call doesn't even exist in the original process, so there's no way to call it in the original process.
As Nick says in his answer, you need either a DLL/shared library or you have to set up some form of interprocess communication so the original process can send data to the new process to be operated on by the function in question and then sent back to the original process.
How about a Dynamic Link Library?
These can be linked/unlinked/replaced at runtime.
Or, if you really want to communicated between processes, you could use a named pipe.
edit- you can also create named shared memory.
for the step 4. we can't directly pass the memory location(address) from one process to another process because the two process use the different virtual memory space. One process can't use memory in other process.
So you need create a shared memory through two processes. and copy your function to this memory, then you can close the newly process.
for shared memory, if in windows, looks Creating Named Shared Memory
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366551(v=vs.85).aspx
after that, you still create another memory space to copy function to it again.
The idea is that the normal memory allocated only has read/write properties, if execute the programmer on it, the CPU will generate the exception.
So, if in windows, you need use VirtualAlloc to allocate the memory with the flag,PAGE_EXECUTE_READWRITE (http://msdn.microsoft.com/en-us/library/windows/desktop/aa366887(v=vs.85).aspx)
void* address = NULL;
address= VirtualAlloc(NULL,
sizeof(emitcode),
MEM_COMMIT|MEM_RESERVE,
PAGE_EXECUTE_READWRITE);
After copy the function to address, you can call the function in address, but need be very careful to keep the stack balance.
Dynamic library are best suited for your problem. Also forget about launching a different process, it's another problem by itself, but in addition to the post above, provided that you did the virtual alloc correctly, just call your function within the same "loadder", then you shouldn't have to worry since you will be running the same RAM size bound stack.
The real problems are:
1 - Compiling the function you want to load, offline from the main program.
2 - Extract the relevant code from the binary produced by the compiler.
3 - Load the string.
1 and 2 require deep understanding of the entire compiler suite, including compiler flag options, linker, etc ... not just the IDE's push buttons ...
If you are OK, with 1 and 2, you should know why using a std::string or anything but pure char *, is an harmfull.
I could continue the entire story but it definitely deserve it's book, since this is Hacker/Cracker way of doing things I strongly recommand to the normal user the use of dynamic library, this is why they exists.
Usually we call this code injection ...
Basically it is forbidden by any modern operating system to access something for exceution after the initial loading has been done for sake of security, so we must fall back to OS wide validated dynamic libraries.
That's said, one you have valid compiled code, if you realy want to achieve that effect you must load your function into memory then define it as executable ( clear the NX bit ) in a system specific way.
But let's be clear, your function must be code position independant and you have no help from the dynamic linker in order to resolve symbol ... that's the hard part of the job.
I have a c lib, algo.lib, which I need to call in my c++ program. I realise that the variables in algo.lib is static, which creates problem for my c++ program, when I call algo.lib multiple times, or use threads to call algo.lib concurrently.
For example, in algo.lib, there is a int a which is initiall set to 0. When I call algo.lib the first time, a will be set to 1000. But when I call algo.lib another time, I want the variables in algo.lib to be in the initial state, that is, a = 0 and not a = 1000.
Is it possible to make algo.lib to become object-oriented, so that when I call its function, it is created as an object and is set to its initial state? And after finish running algo.lib, this object is destroyed?
Yes, it is possible. If you rewrite it. If you only have the binary - then you cannot change this behavior. You can solve it by creating a separate executable that will do what you want with it and then exit, and pass the results back to the main program through some IPC. Basically - wrap it with your own implementation that will effectively initialize the library for each separate call.