I am familiar with concurrent programming in Java which provides a lot of tools for this. However, C++ concurrent programming isn't so easy to start using.
What is the best way to start programming concurrently on C++? Are there any nice libraries which wrap concurrent programming primitives and provide you with more high-level constructs?
I tried QtConcurrent which provides you with nice MapReduce functionality but it is heavily biased towards concurrent computation using Qt so it's not a good choice if you don't want to use Qt.
Are there any other similar libraries? What do people use here?
Thanks for your help in advance,
sneg
There are several choices:
ACE which provides some concurrency constructs
Intel Threading Building Blocks
boost::threads
OpenMP
Qt Threading libraries
Morendil's suggestion (CSP - communicating sequential processes) is truly interesting to take a look at - it's a very different view of threading and one that works well once you wrap your head around it. I first encountered it in the rather esoteric Occam language for Transputers, but the idea has stuck with me.
A more conventional idea: boost::threads work quite well for building thread-based concurrent programs. It's quite low level though.
OpenMP is at a higher level than threads and also quite well-supported.
You could look at CSP, which has a C++ implementation. Way different from Java's threading primitives, though.
This question along with the answers can probably help you a little bit.
Intel's Threading Building Blocks is great for introducing concurrency at the level of individual data-parallel loops, and it takes care of managing threads and allocating work automagically. It can be used in similar ways to OpenMP, but without the need for explicit compiler support.
Related
I want to learn multi-threading in C++ but I'm not sure what type would be most useful. The ones I've seen tutorials on are:
Windows native calls
OpenMP
Boost
(I'm sure that there are probably more.)
What is each one's key features and what are they best used for?
Note: I've already done some multi-threading in C# by manually creating the threads, and more complexity of the threading will just make it more fun. :)
I'd start with pthreads if you have more of a C background, or Boost Thread if you are accustomed to more idiomatic C++. Either is reasonably portable and widely used.
How about TBB? It is portable and has easy to use parallel template patterns, concurrent containers, task scheduler and scalable memory allocaturs. TBB will let you manage threads directly, but that is not necessary in most of the cases.
Personally I would stay away from platform specific threads, unless there an urgent need to do something, well, platform specific.
Boost threads is portable and easy to use, but does have neither parallel patterns nor concurrent containers. You would need to manager threads manually, which can get ugly pretty quickly.
PThreads isn't available on Windows and its C. You really want to do multi-threading in C++, not C. RAII mixes well with mutexes and scoped locks.
Another option is PPL in Visual C++ 2010. It is similar to TBB, but as you may guess available for Windows only.
OpenMP is easy to use, but not very flexible. Since you already learned C++, you should use something more serious, such as TBB or PPL. For some strange reason Visual C++ 2010 doesn't support OpenMP 3. Too bad.
If you want to be portable, learn Posix threads. You know, all thread libraries provide more or less the same set of features, so it's up to you, but Posix will give you the basis.
openMP isn't exactly "multi-threading" as you mean it.
WinThreads (Windows) and pthreads (Linux) are POSIX threads and represent probably your best choice to get started. It is important to learn the distinction between processes and threads, then learn about the various memory access models that are associated with them. Next, try concurrency approaches like OpenMP and MPI "threads".
There are some basic concepts that will get repeated. Learn them well.
I'd like to start learning multithreading in C++. I'm learning it in Java as well. In Java, if I write a program which uses multithreading, it will work anywhere. However in C++, doesn't multithreading rely on platform-specific API's? If so, that would seem to get in the way of portability.
How can I do multithreading in C++ without causing portability issues? Is boost's thread library a good solution?
As a sidenote - how is it even possible to implement multithreading as a library? Isn't that something that has to be done by the compiler?
If you do not have a compiler that supports C++0x yet (available with visual studio c++ 2010 for example), use boost threads. (Unless you use a framework that already supports threading, which is not the case - you wouldn't ask the question otherwise -). These boost threads became actually the standard in the brand new C++. Before that time C++ itself was thread unaware.
TBB Threading Building Blocks might also be interesting to you if you want to learn other aspects in parallel programming.
Regarding Qt: if you only want threading support it is complete overkill. It has horribly slow round trip times from compiling to result. It is really well designed thought. But not an official standard like the C++0x threads from boost. Therefore I would not take it as a first choice.
In C++, yes threading is platform specific. However, many threading libraries encapsulate the nuances of threading on various platforms, providing a uniform API with which to write your threaded app, so you don't have to worry about platform specific details.
Boost threading library is a very good solution.
I also recommending checking out ACE as well.
Let's start backward:
How is it possible to implement threading in a library ?
It isn't, at least not in (pure) C++. This requires language support (the compiler is only an implementation).
At the moment 2 things are used:
assembly code for some parts (like in the pthread library)
specific compiler instructions for others (dependent on the compiler and platform)
Both are brittle and require a tremendous amount of work for portability. Basically it means lot of #ifdef portions in the code to test for the compiler and targetted architecture, test for the support of some directives etc...
That is why it was deemed necessary to add threading support in C++0x.
How do I do multithreading ?
Even before you choose a library, you should choose a method. There are 2 ways of programming multithreaded applications (and you can combine them):
Communicate by sharing: this means using mutexes, atomic operations, etc... you can use pthread on Linux platforms, but I would recommend Boost.Thread (among others) for its portability.
Share by communicating: more recent, and adapted to distributed computations, this stems from the functional languages. This means passing messages from one thread to another and not sharing any resources. You can use FastFlow or Intel's Thread Building Blocks aka TBB.
You can conceivably merge the two, but it would be better not to. Personally I have found the description of FastFlow totally awesome: it encourages lock-free programming. Also, the main advantage of the second method is that it's better adapted to multi-processes programming and scales to distributed environments.
To begin with, I would recommend focusing on either one and build some applications with it. When you're comfortable you may try out the other, but be ready to start anew, they are that different.
//This program explains how pthread works, here 5 thread are trying to update a global variable simultaneously but with locking synchronization in maintained
#include<iostream>
#include<pthread.h>
using namespace std ;
#define MAX_NO_THREAD 5
int global_sum = 0 ;
pthread_mutex_t lock ; //Declared global lock mutex object
void *print_fun(void *arg)
{
cout<<"\nThread id : "<<(int)arg;
pthread_mutex_lock(&lock) ; //aquiring lock on piece of code
for ( int j=0; j<100000000; j++)
{
global_sum++ ;
}
pthread_mutex_unlock(&lock) ; //reomving lock on peice of code
cout<<"\nGlobal Sum : "<<global_sum ;
}
int main()
{
int i = 0 ;
pthread_t threads_obj[MAX_NO_THREAD] ; //Initializing object array for thread
pthread_mutex_init(&lock, NULL) ; //Initalinzing lock object for thread
int st ;
for ( i=0; i<5; i++)
{
pthread_create(&threads_obj[i], NULL, *print_fun, (void *)i) ;//Initializing threads calling function print_fun
pthread_join(threads_obj[i], 0) ; //Forcing main thread to main until these thread complete
}
pthread_mutex_destroy(&lock) ; //Destroying lock object
}
//compile this program using -lpthread option with g++
//g++ thread.cc -lpthread
also check out
Qt
To offer a suggestion different from Boost, I use Pthreads (or Pthreads-Win32 on Windows). It's a very do-it-yourself barebones library, but provides you with all you need and nothing else. It's very lightweight compared to Boost and you can easily find C++ wrappers around it to give you higher level abstractions.
you might also consider openmp http://openmp.org. Many compilers support it, including MS, GCC/G++ and Intel. Although you don't get explicit control of threads, its higher level abstraction of parallelism is sometimes more efficient (at coding time as well as runtime), and the code is much easier to understand. It's not going to help you much if you're doing GUI work, but for scalable computation it's worth a look.
The Boost Threading Library is probably the best place to start for C++. Gives you threading contructs, as well as all the mutexes and control objects you need to write a real working multithreaded application.
With C++11, "Thread support library" is introduced under <thread> header.
More info could be found from below links
https://en.cppreference.com/w/cpp/thread
http://www.cplusplus.com/reference/thread/
If you're doing this out of interest to improve your knowledge of different programming models and language skills then the Boost library would be a fine way to go. However I would think long and hard about actually building any production applications using multi-threaded C++.
C++ is challenging enough at times to attain correctness without adding the considerable complexity of shared memory multi-threading. Even the most seasoned programmers would agree that multi-threaded programs are extremely hard to reason about and get right. Even the simplest programs can quickly become hard to test and debug when multi-threaded.
Imperative languages such as C++ or Java or C# (with their mutable variables, shared memory and locking/signalling primitives) are very often the least approachable way to try to build multi-threaded applications. There are usually perfectly good single threaded implementation options to accomplish most user-space (as opposed to kernel or embedded) application problems, including on multi-core machines.
If you really want to build reliable "multi-threaded" applications I would suggest you check out functional languages like Erlang, Haskell, F# or Clojure.
Having no experience with threading in the past, which threading technique in C++ will be the easiest for a beginner? boost::thread or pthreads?
I'll go in the opposite direction of everyone else - learn (or at least familiarize yourself with what is available in) pthreads.
Since boost is mainly just a wrapper around pthreads (on posix platforms) it helps to know what is going on underneath. In attempting to be generic, boost leaves the platform specific functionality unwrapped. In order to get to it you need to use the native_handle() calls. In order to use the native_handle() calls you need to know what the platform offers.
Think of it like sockets. There are dozens of socket classes and frameworks. But ultimately they wrap the underlying platform's socket API. Your understanding is always richer by knowing it - and knowing in what ways your class abstractions might have short comings.
Go for boost::thread. It's closely related to the work on the upcoming C++ standard threads, and the interface is quite easy to use and idiomatic to C++ (RAII instead of manual resource management).
boost::thread is a very nice and portable abstraction. I would certainly use it, but also learn the native thread api, like pthreads, so that you know how threading works on your platform.
Boost.Thread uses the RAII concept for locking, which makes things more exception safe and helps to avoid bugs like forgetting to release a mutex.
I'd say they're pretty close to equal in difficulty. The only big difference I see is that PThreads are pretty widely support (if you're concerned with cross platform porting). Another is that there have been quite a few good books on PThreads, though almost all the concepts will translate over to boost::thread, and many other threading libraries.
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 am involved in a venture that will port some communications, parsing, data handling functionality from Win32 to Linux and both will be supported. The problem domain is very sensitive to throughput and performance.
I have very little experience with performance characteristics of boost and ACE. Specifically we want to understand which library provides the best performance for threading.
Can anyone provide some data -- documented or word-of-mouth or perhaps some links -- about the relative performance between the two?
EDIT
Thanks all. Confirmed our initial thoughts - we'll most likely choose boost for system level cross-platform stuff.
Neither library should really have any overhead compared to using native OS threading facilities. You should be looking at which API is cleaner. In my opinion the boost thread API is significantly easier to use.
ACE tends to be more "classic OO", while boost tends to draw from the design of the C++ standard library. For example, launching a thread in ACE requires creating a new class derived from ACE_Task, and overriding the virtual svc() function which is called when your thread runs. In boost, you create a thread and run whatever function you want, which is significantly less invasive.
Do yourself a favor and steer clear of ACE. It's a horrible, horrible library that should never have been written, if you ask me. I've worked (or rather HAD to work with it) for 3 years and I tell you it's a poorly designed, poorly documented, poorly implemented piece of junk using archaic C++ and built on completely brain-dead design decisions ... calling ACE "C with classes" is actually doing it a favor. If you look into the internal implementations of some of its constructs you'll often have a hard time suppressing your gag reflex.
Also, I can't stress the "poor documentation" aspect enough. Usually, ACE's notion of documenting a function consists of simply printing the function's signature. As to the meaning of its arguments, its return value and its general behavior, well you're usually left to figure that out on your own. I'm sick and tired of having to guess which exceptions a function may throw, which return value denotes success, which arguments I have to pass to make the function do what I need it to do or whether a function / class is thread-safe or not.
Boost on the other hand, is simple to use, modern C++, extremely well documented, and it just WORKS! Boost is the way to go, down with ACE!
Don't worry about the overhead of an OS-abstraction layer on threading and synchronization objects. Threading overhead literally doesn't matter at all (since it only applies to thread creation, which is already enormously slow compared to the overhead of a pimpl-ized pointer indirection). If you find that mutex ops are slowing you down, you're better off looking at atomic operations or rearranging your data access patterns to avoid contention.
Regarding boost vs. ACE, it's a matter of "new-style" vs. "old-style" programming. Boost has a lot of header-only template-based shenanigans (that are beautiful to work with, if you can appreciate it). If, on the other hand, you're used to "C with classes" style of C++, ACE will feel much more natural. I believe it's mostly a matter of personal taste for your team.
I've used ACE for numerous heavy duty production servers. It never failed me. It is rock solid and do the work for many years now. Tried to learn BOOST's ASIO network framework-Couldn't get the hang of it. While BOOST is more "modern" C++, it also harder to use for non trivial tasks - and without a "modern" C++ experience and deep STL knowledge it is difficult to use correctly
Even if ACE is a kind of old school C++, it still has many thread oriented features that boost doesn't provide yet.
At the moment I see no reason to not use both (but for different purposes). Once boost provide a simple mean to implement message queues between tasks, I may consider abandoning ACE.
When it comes to ease-of-use, boost is way better than ACE. boost-asio has a more transparent API, its abstractions are simpler and can easily provide building blocks to your application. The compile-time polymorphism is judiciously used in boost to warn/prevent illegal code. ACE's uses of templates, on the other hand, is limited to generalization and is hardly ever user-centric enough to disallow illegal operations. You're more likely to discover problems at run-time with ACE.
A simple example which I can think of is ACE_Reactor - a fairly scalable and decoupled interface- but you must remember to call its "own" function if you're running its event loop in a thread different from where it was created. I spent hours to figure this out for the first time and could've easily spent days. Ironically enough its object model shows more details than it hides - good for learning but bad for abstraction.
https://groups.google.com/forum/?fromgroups=#!topic/comp.soft-sys.ace/QvXE7391XKA
Threading is really only a small part of what boost and ACE provide, and the two aren't really comparable overall. I agree that boost is easier to use, as ACE is a pretty heavy framework.
I wouldn't call ACE "C with classes." ACE is not intuitive, but if you take your time and use the framework as intended, you will not regret it.
From what I can tell, after reading Boost's docs, I'd want to use ACE's framework and Boost's container classes.
Use ACE and boost cooperatively. ACE has better communication API, based on OO design patterns, whereas boost has like "modern C++" design and works well with containers for example.
We started to use ACE believing that it would hide the platform differences present between windows and unix in TCP sockets and the select call. Turns out, it does not. Ace's take on select, the reactor pattern, cannot mix sockets and stdin on windows, and the semantic differences between the platforms concerning socket writablility notifications are still present at the ACE level.
By the time we realized this we were already using the thread and process features of ACE (the latter of which again does not hide the platform differences to the extent we would have liked) so that our code is now tied to a huge library that actually prevents the porting of our code to 64 Bit MinGW!
I can't wait for the day when the last ACE usage in our code is finally replaced with something different.
I've been using ACE for many years (8) but I have just started investigating the use of boost again for my next project. I'm considering boost because it has a bigger tool bag (regex, etc) and parts of it are getting absorbed into the C++ standard so long term maintenance should be easier.
That said, boost is going to require some adjustment. Although Greg mentions that the thread support is less invasive as it can run any (C or static) function, if you're used to using thread classes that are more akin to the Java and C# thread classes which is what ACE_Task provides, you have to use a little finesse to get the same with boost.