In my c++ code (my_app) I need to launch external app (app_ext) that dynamically loads my library (dll,so) written in fortran (lib_fort). From this library (lib_fort) I need to call back to some method from my_app, synchronously.
So its like that:
(my_app) --launches--> (app_ext) --loads--> (lib_fort) --"calls"--> (my_app)
app_ext is not developed by me.
Do you have any suggestions how to do it, and what's most important, do it efficiently??
Edit:
Clarification. Launching external app (app_ext) and loading my library from it (lib_fort) will happen only once per whole program execution. So that part doesn't need to be ultra-efficient. Communication between lib_fort and my_app is performance critical. Lib_fort needs to "call" my_app millions of times.
The whole point is about efficient inter-process communication.
My_app role after launching app_ext is to wait and serve "calls" from lib_fort. The tricky part is that solution needs to work both for distributed and shared memory environment, i.e. both my_app and app_ext+lib_fort on single host (1) and my_app and app_ext+lib_fort on different machines (2).
In (1) scenario I was thinking about MPI, but I'm not sure if it is possible to communicate with MPI between two different applications (in contrast to single, multi-process, MPI application).
In (2) scenario probably some kind of inter-process communication using shared memory? (or maybe also MPI?)
OK, the real issue is how to communicate between processes. (Forget MPI, that's for a different kind of problem.) You may be talking about COM (Component Object Model) or RPC (Remote Procedure Call) or pipes, but underneath it's going to be using sockets. IME the simplest and most efficient thing is to open the socket connections yourself and converse over those. That will be the rate-limiter and there really isn't anything faster.
Related
I am new in multi-processing. I am creating an app in modern c++ that communicates with PLCs by modbus TCP. Thus, I have created my library to achieve that and I run the communication process on a different thread and the main thread communicates with it by a shared queue and events. It works well.
Now, I would like to design another app that has a different purpose that would sometime run in parallel to the first one. It still needs to communication with the PLCs. Should I also implement it with multithreading, opening a new canal of communication in a thread? Or should I implement some unique communication process and that every executables would connect to via some pipe? What is the difference between the two and is there a logic to use/exclude one of those solutions?
I see advantages in the multi-threading solution:
If the client fails, it only affects one program until reconnexion,
Shared memory is useful,
It is already implemented in my case
But I also see several advantages for the multi-processing approach. One communication client could be used by many apps. Also among them, it appears to be better for optimization.
I thank you in advance for your help.
I'm working on an application (C++ combined with Qt for graphic part) to be run on an embedded Linux platform. I need know how to divide the application in different "cores" each one taking care of a different part of the application in such a way to improve stability, efficiency and security of the application itself.
My doubt is: is it more convenient to divide functionalities into threads or to fork different processes?
Let me provide a functional view of the application: there are different user interfaces each one allowing users to do more or less the same things (don't mind about data consistency, I've already solved this problem). Each of these interfaces must act as a stand-alone (like different terminal of the same system). I want all of them to send and receive messages from the same "core" which will take care of updating application data or do other proper stuff.
What's the best way to implement the division between the inner "core" and a user interface?
For sure I'm missing some knowledge but so far I came up with two alternatives:
1 - fork a child from father "core" and let the child execute a specific UI program (I have no practical experience of doing this so how, in this case, can I make father and child communicate (baring in mind that child is a new process)?)
2 - create different threads for each core and UI.
I need this division because the application is required to be as stable as possible and capable of restarting a UI in the case of a crash. Keep in mind also that the overall application wont have infinite memory and resources available.
Thanks in advance for your help, regards.
There are a several reasons why going down the separate process route might is a good choice in an embedded system:
Decoupling of component: running components as seperate processes is the ultimate decoupling. Often useful when projects become very large
Security and privilege management: Quite likely in an embedded system that some components need elevated privilege in order to control devices, whereas others are potential security hazards (for instance network facing components) you want to run with as little as little privilege as possible. Other likely scenarios are components that need real-time threading or to be able to mmap() a lot of system memory. Overallocation of either will lock your system up in a way it won't recover from.
Reliably: You can potentially respawn parts of the system if they fail leaving the remainder running
Building such an arrangement is actually easier than others here are suggesting - Qt has really good support for dbus - which nicely takes care of your IPC, and is used extensive in the Linux desktop for system management functionality.
As for the scenario you describe, you might want to daemonise the 'core' of the application and then allow client connections over dbus from UI components.
Running the UI in a different thread won't give you much in the way of additional stability -- the other thread can trash your heap of the engine, and even if you terminate the thread any resources it has won't be recycled.
You can improve stability a bit by having a really strong wall of abstraction between the Engine and the UI. So this isn't completely futile.
Multiple processes require lots of hoops to jump through -- you need a method of IPC (interprocess communication).
Note that IPC and to a lesser extent walls of abstraction can add to the overhead of your program.
An important question to ask is "how much data has to pass between the UI and the Engine?" -- if it is little enough data (like "start the task" from UI to engine, and "this task is 50% done" from engine to UI), IPC is less of a hassle. If you are an interactive painting application with real-time full-screen updates of an image, IPC is more annoying and less practical.
Now, a quick google on Qt and IPC tells me that there is a Qt extension for embedded linux that allows the Qt signals and slots to pass messages between processes: Qt COmmunications Protocol (QCOP). One issue I have had with frameworks like this is that it can easily lead to entanglements between the client and server state that can compromise stability on the other end of the communications pipe, compared to relatively simple protocols.
I'm investigating as to whether there is a framework/library that will help me implement a distributed computing system.
I have a master that has a large amount of data split up into files of a few hundred megabytes. The files would be chunked up into ~1MB pieces and distributed to workers for processing. Once initialized, the processing on each worker is dependent on state information obtained from the previous chunk, so workers must stay alive throughout the entire process, and the master needs to be able to send the right chunks to the right workers. One other thing to note is that this system is only a piece of a larger processing chain.
I did a little bit of looking into MPI (specifically Open MPI), but I'm not sure if it is the right fit. It seems to be geared to sending small messages (a few bytes), though I did find some charts that show it's throughput increases with larger files (up to 1/5 MB).
I'm concerned that there might not be a way to maintain the state unless it was constantly sent back and forth in messages. Looking at the structure of some MPI examples, it looked like master (rank 0) and workers (ranks 1-n) were a part of the same piece of and their actions were determined by conditionals. Can I have the workers stay alive (maintaining state) and wait for more messages to arrive?
Now that I'm writing this I'm thinking it would work. The rank 1...n section would just be a loop with a blocking receive followed by the processing code. The state would be maintained in that loop until a "no more data" message was received at which point it would send back the results. I might be beginning to grasp the MPI structure here...
My other question about MPI is how to actually run the code. Remember that this system is part of a larger system, so it needs to be called from some other code. The examples I've seen make use of mpirun, with which you can specify how the number of processors, or a hosts file. Can I get the same behavior by calling my MPI function from other code?
So my question is is MPI the right framework here? Is there something better suited to this task, or am I going to be doing this from scratch?
MPI seems reasonable option for your task. It uses the SPMD architecture, meaning you have the same program executing simultaneously on possibly distributed or even heterogeneous system. So the choice of process with rank 0 being the master and others being the workers is not mandatory, you can choose other patterns.
If you want to provide state for your application, you can use a constantly living MPI application and master process sending commands to worker ones over time. You probably should also consider saving that state to disk in order to provide more robustness to failures.
Running of an MPI process is done initially by mpirun. For example, you create some program program.c, then compile it using mpicc -o program program.c. Then you have to run mpirun -np 20 ./program <params> to run 20 processes. You will have 20 independent processes each having its own rank, so further progress is upon your application. The way these 20 processes will be distributed among nodes/processors is controlled by things like hostfile etc, should look at the documentation more closely.
If you want your code to be reusable, i.e. runnable from another MPI program, you generally should at least learn what MPI Communicator is and how to create/use one. There're articles on the net, keywords being "Creating MPI library".
If the code using your library is not to be in MPI itself, it's no huge problem, your program in MPI is not limited to MPI in communication. It just should communicate inside it's logic through MPI. You can call any program using mpirun, unless it tries calls to MPI library, it won't notice that it's being run under MPI.
If you are getting up and running with a cluster and mpi, then I recommend having a look at boost mpi. Its a c++ wrapper over an underlying mpi library (such as openmpi or mpich2). I found it very useful.
Your idea of sending messages back and forward, with each node requesting a new message when it is finished until a handshake saying "no more messages" is provided sounds a good one. I had a similar idea, and got a simple version up and running. I just put it on github for you in case you want to have a look. https://github.com/thshorrock/mpi_manager. Most of the code is in the header file:
https://github.com/thshorrock/mpi_manager/blob/master/include/mpi_manager/mpi_manager.hpp
Note, this was just a bit of code that was used to get me up and running, its not fully documented, and not a final version but its fairly short, works fine for my purposes and should provide a starting point for you.
Have a look at FastFlow. They use a data flow model to process data. It is extremely efficient if this model is suitable for you.
RayPlatform is a MPI framework for C++. You need to define plugins for your application (like modules in Linux).
RayPlatform is licensed under the LGPLv3.
Link: https://github.com/sebhtml/RayPlatform
It is well documented also.
An example application using RayPlatform: https://github.com/sebhtml/RayPlatform-example
edit: added link
I have an application (A) that needs to launch another application (B). I need to pass data between the applications. I can think of two approaches. The first is to open a socket. The second is to share data via a dll.
The opening socket approach is straight forward.
The dll approach I have some questions? I can load plug-in dlls into B. I want to create a dll that A can use to pass data to B. When loading dlls, is only one instance of the dll loaded? If so, does this mean that data can be shared between applications that load the dll?
What is the better choice?
Are there other ways of doing this?
You can't effectively share data via a DLL. Other ways:
disk files
pipes
shared memory
messages
RPC
CORBA
COM
etc.
The simplest method (assuming Windows since you mention a DLL) is probably to use CreateProcess and open a pipe to the child process, as described in simplified form here: http://msdn.microsoft.com/en-us/library/ms682499.aspx
Named Pipes can be an alternative, especially if you aren't in control of the lifetime of all of the processes. http://msdn.microsoft.com/en-us/library/aa365590.aspx
For simple cases, mailslots may be a sufficient alternative.
http://msdn.microsoft.com/en-us/library/aa365574.aspx#base.using_a_mailslot_for_ipc
Here's a longer list of various Interprocess Communication techniques for Windows.
http://msdn.microsoft.com/en-us/library/aa365574.aspx
For something happening locally, using sockets seems sort of overkill. Plus you have to implement your own security mechanism to prevent spoofing attacks, rather than depending on the integrated security mechanism of most of the other IPC methods.
Its always good to explore alternative possible solutions, but I personally believe that using sockets as a transport layer for data between applications is not only future proof, but scalable as well. Using sockets will eliminate the need for you to write copious amounts of OS specific code, which could proclude you from porting your application in the future to non-Windows operating systems.
I would suggest sockets.
You can have a shared cache (example a windows service or hidden process) that can be listening - returning data to all subscribers. This using a Observer pattern approach.
I would agree somewhat with Juan Zamora M except that the service providing the data should have an API that can be requested when needed not pushed when changed via listeners.
This might help. Sharing Files and Memory
Suppose I have a daemon that is sharing it's internal state to various applications via shared memory. Processes can send IPC messages to the daemon on a named pipe to perform various operations. In this scenario, I would like to create a C++ wrapper class for clients that acts as a kind of "Remote Proxy" to hide some of the gory details (synchronization, message passing, etc) from clients and make it easier to isolate code for unit tests.
I have three questions:
Generally, is this a good idea/approach?
Do you have any tips or gotchas for synchronization in this setup, or is it enough to use a standard reader-writer mutex setup?
Are there any frameworks that I should consider?
The target in question is an embedded linux system with a 2.18 kernel, therefore there are limitations on memory and compiler features.
Herb Sutter had an article Sharing Is the Root of All Contention that I broadly agree with; if you are using a shared memory architecture, you are exposing yourself to quite a bit of potential threading problems.
A client/server model can make things drastically simpler, where clients write to the named server pipe, and the server writes back on a unique client pipe (or use sockets). It would also make unit testing simpler (since you don't have to worry about testing shared memory), could avoid mutexing, etc.
There's Boost.Interprocess library, though I can't comment on its suitability for embedded systems.