I have a quick question. I am supposed to create a small multithreaded program to grab data from multiple sensors and I have knowledge of both pthreads and qthreads. I have access to both libraries. personally I am biased towards using Qt because of its design and various functionalities. But is there a significant advantage on using one vs the other?
Thanks
QThreads are built upon pthreads. They provide an Object Oriented abstraction, making it easier to work with threads. Besides QThreads are portable, they can run on whatever system using the underlying thread system, while pthreads are specific of POSIX systems.
The almost-only disadvantage of using QThreads is that you'll need to link your application against Qt; this dependence could make it a little more difficult to distribute your application.
But you have to know what QThreads use event loop for managment it, so you can't just kill thread like with pthread. If threads do long and hard work, it's not possible to stop it while it not to be released. In some case it's important.
I think at the heart of things, QThread under linux uses pthread. I'm not sure what is under the hood for the Windows side of it. Unless there are some some specific pthread API functions that you need that aren't available with QThread, I would stick with QThread just to benefit from the portability that it will give you. I wouldn't expect there to be any significant performance difference. Qthread will also allow you to use the signal/slot mechanism across thread boundaries.
Related
I am linking against a library that is built with OpenMPI support for internal processes.
My application is being built with no MPI support, and I link against this library. I have no idea what is happening behind the hood with regards to mpi. If library A loads/calls functions from openmpi, does this mean I can run my application with runmpi to get the library processes to distribute themselves? If I decide to make the application MPI aware and want to use mpich2 instead of OpenMPI or if I want to use Library B that is linked against mpich instead of openmpi, will the library and my application behave themselves in their individual message spaces? Is it typical to force application developers to explicitly link an mpi implementation to use an mpi-enabled library?
The normal practice is that the developer ultimately compiles and links everything against a single MPI implementation. Where there are libraries depending on MPI, I typically see builds of the library for each available MPI implementation on a system. If you could somehow manage to link in two MPI implementations, and come up with their separate MPI_Init and MPI_COMM_WORLD definitions to use in the separate pieces of code, it might even work. That would be really tenuous, though. Don't do it.
As for your earlier question, it is almost possible to have an application call into a library using MPI and just have it do the right thing. First, the code will have to call MPI_Init somewhere. whether that's in the client or wholly encapsulated in the library may vary. The library will have to know what MPI communicator it's supposed to use; typically the client code would pass one in. Finally, the client code will have to take account of the fact that it will run on all MPI processes, not just one of them. So if it does any IO or other computation that should only happen in one process, then you'll need to set conditions accordingly.
I have two questions:
Is there any API in Qt for getting all the processes that are running right now?
Given the name of a process, can I check if there is such a process currently running?
Process APIs are notoriously platform-dependent. Qt provides just the bare minimum for spawning new processes with QProcess. Interacting with any processes on the system (that you didn't start) is out of its depth.
It's also beyond the reach of things like Boost.Process. Well, at least for now. Note their comment:
Boost.Process' long-term goal is to provide a portable abstraction layer over the operating system that allows the programmer to manage any running process, not only those spawned by it. Due to the complexity in offering such an interface, the library currently focuses on child process management alone.
I'm unaware of any good C++ library for cross-platform arbitrary process listing and management. You kind of have to just pick the platforms you want to support and call their APIs. (Or call out to an external utility of some kind that will give you back the info you need.)
This question might sound a bit weird...
Imagine I have an MPI application, but I don't have a system with MPI installed.
So I want to compile the application with no MPI support (1-process, 1-thread) without modifying source code.
Is that possible?
I found somewhere a "mimic_mpi.h" wrapper which is supposed to do exactly what I want. But there were some MPI functions missing in there (e.g., MPI_Cart_create, MPI_Cart_get, etc.), so I didn't succeed.
mimic_mpi.h http://openmx.sourcearchive.com/documentation/3.2.4.dfsg-3/mimic__mpi_8h-source.html
mimic_mpi.c http://openmx.sourcearchive.com/documentation/3.2.4.dfsg-3/mimic__mpi_8c-source.html
Do you know any other approach I could use to compile MPI apps with no MPI support?
Thanks in advance!
You can run a "real" MPI application easily with a single process. In practice this even works without using mpiexec/mpirun although I'm not sure if that's officially supported. That said a full and confirming 1-process MPI "serial" implementation would probably become rather complex and its own library - so in that case, why not just use a real full MPI implementation?
I hope you see the circle I'm trying to draw:
If you want full MPI behavior, just use an MPI implementation - regardless if it's just limited to a single process.
In practice, applications that want to be able to function with or without MPI often seem to use their own MPI abstractions using domain specific communication wrappers, #ifdef HAVE_MPI or more complex macros.
I want to use Asio and Qt together ? each of them have a two method that must be called and each of them are blocking for example : Asio has io_service.run() and qt has QCoreApplication.exec() if I run one of them then another cannot be run.
I have two solutions:
create another thread and call io_service.run() from that.
create a timer with 100ms cycle and call io_service.poll() from same thread that call QCoreApplication.exec().
These solutions are correct?
This is simple solution and works on every platform, but it has some minor drawback. You are introducing latency to asio-part of your application, which may be acceptable or not - depends on your case.
You may be interested in my solution, that makes real integration of asio and QT mainloops.
Look also at the following question for more on this topic: How to integrate Boost.Asio main loop in GUI framework like Qt4 or GTK
You definitely want to look into multi-threading your application. Qt helps you out with pretty good platform-independent threading classes. You'll also need to address communication between objects owned by different threads and also will need to bear in mind that painting is limited outside of the GUI thread.
I have planned to learn parallel computing. Now I'm thinking of MPI or TBB. In fact, I do not have much experience at this. I suppose I better start with something easy to manage. At first, I may try something like coarse-grained code. Which one could be easier for me? Thanks.
It depends on your definition of parallelism and what you are trying to acheive. The point of TBB is to take advantage of multi-core processors. In this scenario, parallelism means running on multiple cores simultaneously.
However, the main benefit of MPI is distributed memory parallel computing. In this scenario, running your application on a cluster of different physical machines and communicating with each other over TCP or another proprietary protocol.
In summary, depending on your problem space one or the other may be better. It really depends on the problem you are trying to solve.
MPI and TBB are very, very different in approach.
MPI is basically a message passing library. This is more difficult to use for developing a threaded application, since it enforces much stricter isolation rules. It does, however, allow you to scale up to multiple processes, running on multiple systems.
TBB, on the other hand, is really geared towards making threading within a single application much simpler and more approachable. It is very similar in approach to Microsoft's concurrency runtime, and even the TPL in the .NET world.