I'm considering two options to run asynchronous code: Qt Concurrent and std::async. Given that I'm writing a GUI app with Qt, it makes sense to go with Qt Concurrent. However std::async also seems good and supported by all major compilers.
Should I use Qt Concurrent or std::async for new code? What else should I look for when comparing the two?
Given that I'm writing a GUI app with Qt, it makes sense to go with Qt Concurrent
I would say, it is not so simple. I would personally utilize the standard library as much as I can. However, there are constraints to take into account:
Do you need to support your software on platforms not supporting at least C++11?
If the question is yes to that, using Qt solutions is a better option in a Qt based software. That being said, even for that, you could have different Qt solutions depending on your need. One is the thread weaver from KDE, but let us not go that far for now...
Another question, that you could ask from yourself:
Do you already have an existing code base where that is used throughout?
Depending on the answer, this could also provide further aspect for the decision, whether you prefer consistency, or forward thinking.
There is also another question here to be asked:
How much of QtConcurrent do I need?
Depending on the exact answer, it may or may not be a better alternative. Note that, not every functionality of QtConcurrent is in the standard library just yet, for instance something like QFutureWatcher with the Qt signal-slot mechanism.
So, yes, as a Qt user, I would suggest to use the standard library as much as possible. These days, Qt even explicitly depends on them, so will not run on platform not supporting it. Also, the general direction put seems to be this in Qt Project proper. For instance, lots of stuff got obsoleted in the QtAlgorithms, but that is just one of those.
Qt Concurrent lets you run a function in another thread using QtConcurrent::run(). So i think you can only compare QtConcurrent::run() with std::async.
Qt Concurrent is so sophisticated and has many useful features. It includes APIs for parallel list processing and lets you create multi-threaded programs without using low-level threading primitives such as mutexes or semaphores. It also adjusts the number of threads used according to the number of processor cores available.
I think using Qt Concurrent is so cool because of its high-level APIs and ease of use.
Related
I'm experimenting with multithreading in Windows and was wondering whether I should
use Win32 API
use POSIX Threads for Windows
Learning Pthreads would be useful if I tried to develop such applications on different platforms - but am I losing anything by not learning Win32 API? Or are both similar enough so that learning one allows me to figure out the other easily?
Use Boost Threads. When C++0x comes along, we will have std::threads. Boost threads has the closest implementation to std threads.
else use pthreads. Pthreads is second closest to std::threads, and formed the main basis of std threads and boost threads.
else do windows threading directly. You can still learn how threads work, and form a mental model of things. It just tends to use synchronization primitives that are a bit non-standard.
If you're going to do much Windows programming, it will pay to learn the basic Win32 threading constructs: critical sections, interlocked functions, CreateThread, WaitFor*Object, etc. These aren't hard to understand, and they translate transparently to equivalent objects in other threading frameworks.
However, for more advanced threading constructs such as semaphores, events, etc., I would use the pthreads library, since the documentation on those tends to be clearer and examples more abundant.
If you're using C/C++, try to use the thread functions of the C/C++ runtime.
If you use the Win32 (or other non-CRT functions to create threads) the CRT might not be initialized correctly in the new thread, causing all kinds of problem (you can read about it here: http://www.codeguru.com/forum/archive/index.php/t-371305.html).
However, most thread-functions (in the CRT, Win32 or pthread) are all based around the functionality to create threads, synchronize threads and destroy threads. In practice this isn't always that easy to use.
In the last year, there is a trend to go to task-based threading (well, I call it that way, I don't know what the official name is). Instead of starting a thread and then executing some logic in it, in task-based threading you create a task and then ask the 'threading logic' to execute the task.
Systems that support this new way of working with threads are:
Visual Studio 2010 (we'll have to wait a few days for it)
Intel Threading Building Blocks
Visual Studio 2010 even has (it seems) special debugging logic to debug the 'parallel tasks'.
Take a look at std::thread
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2184.html
And a introduction
http://www.devx.com/SpecialReports/Article/38883
I've found that sticking with pthreads saves my sanity on three counts:
I don't have to fight through
WinAPI docs, which aren't habitually
of any quality.
Anyone that does much with threads
can help out with
pthreads. I've found infinitely more good sources of information about pthreads online.
Whenever I implement anything more
complicated that "Hello World" with
the WinAPI, I find it takes far
longer than one could reasonably
expect. That's just my empirical
input, though.
As far as capabilities are concerned, I've never found pthreads to be lacking in anything, so I don't think I've ever found the need to look elsewhere. There is also a great deal to be said for learning a library that you'll be able to use in any environment you tackle.
What is the easiest way to create multithreaded applications with C/C++?
unfortunately there is no easy way. Couple of options: pthread on linux, win32 api threads on windows or boost::thread library
There is no easy way to create a multithreaded application in any language.
Just to mention it because it hasn't been mentioned: a compiler with OpenMP support (http://openmp.org/wp/)
Qt has a pretty
threading support and documentation
but as others have cautioned this is not for beginners. The doc link I gave itself points to a short reading list
pthreads!
https://computing.llnl.gov/tutorials/pthreads/
There is no simple answer to this. It depends very heavily on what you hope to gain from multithreading, the platform/compiler, and which threading model you want to use. Every threading API has its pitfalls.
And just because no one has mentioned it so far, OpenMP is another option that is supported in many modern mainstream compilers and is intended to simplify the use of concurrency.
http://openmp.org/wp/
It's been a while since I worked in C++ and I haven't seen the Boost threading support, but I found it very helpful to encapsulate semaphore services provided by the OS, usually either POSIX or Win32, in simple classes that would acquire locks, and release them in the destructors, making their use fairly simple.
void operateOnSharedResource(SharableResource & foo) {
MutexLock lock(foo.getMutex());
// do stuff to foo
// implicit call to MutexLock dtor performs release
}
Ultimately there are lots of simple tricks like this to ease thread programming and I'd be surprised if Boost didn't have something like this by now (EDIT: It does and it's documented in Lock Types).
Regardless, the main problem with writing multi-threaded code isn't going to be solved by any third party library, and that's understanding where your code can be parallelized usefully, and where shared resources are going to be touched and must be accounted for. Here's a few rules of thumb I use when writing multi-threaded code.
Try to minimize the number of shared resources
Try to encapsulate shared resources in class wrappers that make all operations atomic.
Make worker threads as simple as possible
Proper encapsulation really does wonders for writing safer multi-threaded code, because the fewer things you can see, the fewer things can have a race condition.
I'm not sure about the easiest, but IMO the most user-friendly threading library is the one included in the Poco C++ project. For a preview have a look at the Thread.h header file.
The C++0x specification includes threading facilities (one of my favorite new features). Soon it won't matter what OS you're compiling for! Just look how easy it is to create a new thread and join back to the creator thread:
#include <thread>
#include <iostream>
class SayHello
{
public:
void operator()() const
{
std::cout<<"hello"<<std::endl;
}
};
int main()
{
std::thread t((SayHello()));
t.join();
}
Visual Studio 2010 is implementing parts of C++0x but we're still waiting on the threading facilities.
Boost.Thread is relatively easier because it's portable, well-documented and has high-level API such as scoped_try_lock.
Besides the ones already mentioned, ACE is another popular and widely deployed C++ framework that provides thread encapsulations across multiple platforms. It's style of C++ isn't as modern as Boost.Thread, for example, but it is quite mature.
I would say with Qt. Qt Threads and Qt Concurrency are probably worth googling.
Posix Thread is quite good, they also come with great documentation and tutorials.
Not as easy as java threads, but still quite good.
The easiest way is by avoiding/minimizing mutable shared state.
Once you have mutable shared state, you need to deal with locking which is where the bulk of the difficulty in writing multi-threaded programs exists.
This depends entirely on what you're doing. If you can fit what you're doing into OpenMP then that is the way to go. Otherwise you may want to look at Intel's TBB. TBB offers several workflows which you should be able to fit into, but the library is dual licensed and you may not be able to accept either license. If both OpenMP and TBB are out, then you should consider your operating system's thread pools abilities.
At some point you may need to bite the bullet and use Boost.Thread. If so, you'll want to look at what makes multithreading in C++ hard (good to read even if you're not using C++0x: "It's not the threads themselves, it's the communication that causes problems. Mutable shared state introduces implicit communication," page 3).
I heard Qt API is written in pretty outdated C++ language. Is it true?
Are there any plans to make it use more modern C++ language? Are there any official information on this?
Are there any projects with the aim to wrap current Qt API constructs with more modern C++?
UPDATE
That's more to this question than templates and that's not the question only about the current state of affairs (that's why I tagged it with the future tag).
UPDATE
I'm especially concerned with Qt API as this is what users of this framework work with.
Using modern C++ language in API makes it more robust, flexible and easier to use.
What kind of C++ is used inside Qt is far less important to me.
Qt is known not to use templates, one very useful modern c++ feature. But that does not mean that there is a need for a wrapper to Qt's API. Qt uses in-house precompilers to address the same issues. Some don't like this approach, but Qt's API is very simple and efficient, and i don't believe there is a real need to modernize it.
In particular, signals&slots, a very impressive feature from Qt, can be achieved using templates (see boost.signals library), but the way Qt has implemented it is still much more efficient.
I'd say "don't worry and use Qt as is".
EDIT:
Sorry i forgot about template containers provided with Qt. But still, Qt's API makes very little use of template classes. This does not mean that they don't use them inside Qt though or that their way of coding is obsolete.
Boost.Signals are probably more powerful than Qt signals/slots but, as far as i can tell, there is no arguing about which is simpler to use. One very convincing implementation of the KISS principle.
Qt uses modern variants of the C++ language - currently C++98, and yes Templates are also used where it's appropritate. Qt has some support for STL. See e.g. http://qt-project.org/doc/qt-5.1/qtcore/containers.html - and convenience functions for e.g. std::string. It's all in the docs: http://qt-project.org/doc/qt-5.1/qtdoc/index.html ;) The question about templates vs moc is one we get so often we have added it to our documentation; http://qt-project.org/doc/qt-4.8/templates.html
Qt sources contain the pattern "template <" 1280 times in src/corelib alone. I fail to see how this can be mistaken as "Qt is known not to use templates"
Unlike Boost.Signals, Qt's implementation of signals/slots is thread-safe via the use of queued connections. On May 2nd, 2009, however, Boost.Signals2 was released and brought with it the much-desired thread-safety. From the developer point of view, Qt's implementation of signals/slots is much easier to use, mostly due to the fact that it does not use templates. For an in depth read of why Qt uses moc instead of templates for signals and slots, here's a page from their documentation.
For those wondering why Qt has its own set of container classes, I'm pretty sure that the main motivation was to offer implicit sharing. All of the container classes are implicitly shared, so whenever a QList is copied, only a pointer to the data is copied. See here for more information on shallow copying within Qt.
To directly answer your question,
Qt's API is comprehensive. I'm pretty sure they'll come out with a QApp::ParkMyCar() function some time. They sometimes implement multiple ways of doing the same thing, with different positions on efficiency vs ease of use. Check out their (excellent) documentation. It is as comprehensive, and has saved my ass more than once.
From what I've seen of the Qt source code, the code is highly efficient.
Take a look at the features in the install configuration - you can turn on/off support for various features (including STL, threading and even the GUI). Further, when the Trolls made Qt 4 ground-up, they did not trade off features against code-jazz -they just delivered more of both. Given the quality of their programmers and their way of updating major versions, I don't think we need to worry about Qt (or parts) getting outdated.
Qt's target market (for desktops) is the MamaPapa company that makes Hello Kitty desktop alarm clocks, and wants to Code once and rest assured that it runs on all "sane" systems - Windows 98 and above, popular Linux distros and Mac OS X. This means pandering to the LCD of all the main compilers in each kind of system. If this means keeping template-wizardry in their code to a minimum, so be it.
Throughout the Qt 4.x lifetime, I doubt that it makes sense to rewrite parts of Qt to use e.g. "more modern" C++. This is because of the premise that all releases in the same major version of Qt should still be binary compatible. We also can not just obsolete or deprecate classes that the customers still use (although it is perfectly fine to introduce new stuff, even for a limited set of supported compilers).
If finally Qt 5 is almost out of the door, and the modern C++ constructs and features are finally available in the targeted supported platforms and compilers, and doing so will help C++ developers and customers to write better and more powerful code, then why not?
I really don't like the way Qt managed to implement its signals/slots mechanism. Their 'moc' precompiler really smells like a hack to me, and it doesn't even support standard C++.
I think it would be great if Qt could modernize itself to use at least the STL classes. What would be really awesome would be for Qt to use Boost whenever possible (especially Boost.Signals).
I, too, don't like the way Qt adds voodoo magic to C++. It uses so many macros that it awfully reminds me of C. At the moment, there is nothing to indicate that Qt would be kinder to C++ features in the future. I would really like to see it be more like C++ and not a language of its own (e.g. Why do we need std::vector<> and QVector<>? Or Qt signals, Boost.Signals and sigc++?)
Qt is a library and needs to support a wide range of compilers. It still supports MSVC6, e.g. (I think Qt Software is phasing out support for this, though). This limits the more modern C++ features, Qt is able to use.
But this does not mean that you can't use them in your Qt program.
I'm looking forward to an interview in C++ in the coming weeks. (yay) So I have been relearning C++ and studying up. Unfortunately I have realized that I've never implemented threads in C++, and am somewhat concerned about a quiz on concurrency.
As far as I can tell, C++ uses pthreads in Linux and some other device in Windows. Is this correct? Is there another industry standard, more OO way to handle threads in C++ that I should be expected to know? And are there any good web resources that you can point me to for practicing and learning threads in C++?
Thanks!
There is a boost threads library which is probably the closest to a standard.
Generally threads are supplied by the OS so you get whatever the OS supplied. Also peoples first exposure to threading is often in a GUI, to allow a background calculation to not block the GUI, and so people tend to use the thread functions supplied by the particular GUI framework (MFC/Qt etc)
Currently C++ is entirely unaware that threads exist. Different OSes provide threading libraries to make them available. The next version of C++, so called C++0x, is going to make a thread library standard. If I were to start a multithreaded app today I would go with either boost threads or the threads that were a part of any package I might be using i.e. QT or WxWidgets.
Well, until C++0x gets here, there is no standard way to do threading in C++. You can use whatever facilities your operating system provides. So yes, if you are on a UNIX-like operating system, you can use pthreads. On Windows, you can use the Windows API.
There are 3rd party toolkits out there that attempt to provide a uniform and portable threading API, e.g. boost threads and QT.
It is also not difficult to write your own portable abstraction layer either. We did this because the boost API didn't have everything we needed several years ago (e.g. no way to set priority).
In windows the only way to create threads is using the win32 API. Every library you may have that creates threads on windows eventually uses win32 CreateThread()
QT Contains a nice C++ wrapper around a thread that is cross platform. Usually a good practice is to have a MyThread class that contains all the nitty-gritty details of setting up a thread, checking for error codes, getting it's exit code and the like. The MyThread class would have a pure virtual function called run() which is intended to actually do whatever you'd want the thread to do. The user of the MyThread class is expected to inherit from it and implement run() this way you can isolate the user of the class from the details for actually creating the thread.
MyThead also needs to have a method start() which initiates the thread. The thread would start at some entry point inside the class (this usually needs to be a static method) and then this eventually leads to the user's run() method to be invoked.
Beyond Qt, wxWidgets, Boost and native, OS-provided threading facilities, you can just Google around for thread libraries for C++. They are probably more portable and lightweight as well (if all you are looking for is threading). However, if you have a need for more facilities and the aforementioned libraries provide them, then go ahead and use them. Boost is especially good, it has other facilities as well, but admittedly it's threading library, as Brian Neal said, is limited in some regards.
For your interview, neither boost nor qt is helpful at all. you could just use them as the high level libs and interfaces, and no one would ask you how to use boost or qt in such an interview.
For understanding threading and mutex etc, see a document from http://code.google.com/p/effoaddon/downloads/list, named EffoAddons.pdf.
Raw source
http://effoaddon.googlecode.com/svn/trunk/devel/effo/codebase/addons/thrd/src/thrd/thrd.cpp,
high level abstract interface
http://effoaddon.googlecode.com/svn/trunk/devel/effo/codebase/addons/thrd/include/thrd_i.h,
and code support wait and signal
http://effoaddon.googlecode.com/svn/trunk/devel/effo/codebase/addons/queue/include/iqb_ops_i.h.
you'd better study something underlying, not just high level interfaces, though write C++.
I've seen several 'real-world' implementations of threading using C++, and they have all been implemented by someone's writing a Thread class to wrap the underlying O/S API
For example, on Windows there's a CreateThread API: your Thread class would pass its this value to the void* lpParameter parameter of the CreateThread API; and your LPTHREAD_START_ROUTINE, which you implement as a private static method of the Thread class, then needs to cast void* back to Thread*' in order to get theThread` instance.
I am looking for lightweight multi-threading framework for C++. I found POSIX Threads.
Please, share you practical experience with POSIX threads: before I start with it I want to know its pros and cons from real people, not from wiki.
If you practically compared it with anything (maybe, better), it would be interesting to know either.
UPD: cross platform features are really important for me, so I would appreciate this direction described.
UPD2: I already have an experience with one framework for QNX / Win32, but it is not lightweight and - oh, I forgot to mention, - it is commercial, not free, but I need a free one.
I found Boost.Threads to be really nice, especially after the 1.35 rewrite. POSIX threads on Windows is not so trivial, and it's a C API, so I would definitely prefer Boost to it. It has all the stuff you need, is portable and requires little setup.
Another C thread API is GThreads from GLib. There is a 1-to-1 mapping between some gthread and pthread calls such as pthread_create, but gthreads have 2 big features that I have found very useful:
thread pools and
asynchronous queues for sending messages between threads.
The thread pools are very powerful, allowing things like dynamic resizing of the pool. See http://library.gnome.org/devel/glib/2.20/glib-Threads.html
The POSIX threading API is a C API, not C++.
What do you want to use it for? Personally, I find it to be a very clumsy and overly verbose API. But it is your best bet if you want to do cross-platform development on Unix/Linux-like operating systems. It is not natively supported on Windows.
Personally, I would not use a threading or any other OS dependent API directly in your code. Build another abstraction layer on top of it. For example, we built what we call an "OS layer"; a C++ framework for working with threads, semaphores, timers, mutexes, etc. Our code uses this exclusively. Underneath the hood, we have implementations for POSIX, Win32, INTEGRITY, and vxWorks. This lets our code work on a large variety of platforms.
If you don't want to build your own layer, you can look towards reusing many others like Boost, Qt, etc.
I used POSIX a while ago for a program I wrote. It worked fine on Linux and Solaris and it's not terribly complicated to implement. My brother on the other hand is a Windows programmer and preferred boost to Posix. I guess it depends on your target. I found boost to be a bit on the bloated side and had heard bad things about it. My brother thinks it's the greatest thing since sliced bread. I suppose it's a ford vs chevy thing. Everyone will have an opinion.
If you don't like Boost's thread API, then you might want to look at POCO's.
As you are mentioning QNX have a look at ACE. It is a vast framework that is available for many platforms (including QNX).
Others have already mentioned Boost.
You are well advised to use one of these libraries instead of the low level, non portable and error prone C APIs.
Boost threads library is probably your best bet if you work in C++. I had very positive experience with it both on Unix and win32. Avoid ACE - bad design, wrong approach. Also take a look at Intel TBB, though I haven't used it in practice.
I've found it to be pretty similar to the win32 thread API, the only (real) difference you need to be aware of is that win32 mutexes don't block when used on the same thread while posix do. Apart from that, it's a pretty straight forward API.