11

How do the Boost Thread libraries compare against the java.util.concurrent libraries?

Performance is critical and so I would prefer to stay with C++ (although Java is a lot faster these days). Given that I have to code in C++, what libraries exist to make threading easy and less error prone.

I have heard recently that as of JDK 1.5, the Java memory model was changed to fix some concurrency issues. How about C++? The last time I did multithreaded programming in C++ was 3-4 years ago when I used pthreads. Although, I don't wish to use that anymore for a large project. The only other alternative that I know of is Boost Threads. However, I am not sure if it is good. I've heard good things about java.util.concurrent, but nothing yet about Boost threads.

mmmmmm
  • 32,227
  • 27
  • 88
  • 117
user855
  • 19,048
  • 38
  • 98
  • 162
  • 7
    Martin, I think it means "Java is a lot faster than it was before." – zedoo Dec 26 '09 at 13:23
  • 7
    In my experience any time some one says "Performance is critical" without specifics it isn't really that critical at all. Don't choice C++ or Java for performance reasons, choose C++ or Java because you are more familiar with it or you find it easier to program in. – Peter Lawrey Dec 26 '09 at 16:56

6 Answers6

12

java.util.concurrent and boost threads library have an overlapping functionality, but java.util.concurrent also provide a) higher-level abstractions and b) also lower level functions.

Boost threads provide:

java.util.concurrent has also:

A side note: C++ has currently no memory model. On a different machine the same C++ application may have to deal with a different memory model. This makes portable, concurrent programming in C++ even more tricky.

dmeister
  • 34,704
  • 19
  • 73
  • 95
11

Boost threads are a lot easier to use than pthreads, and, in my opinion, slightly easier to use than Java threads. When a boost thread object is instantiated, it launches a new thread. The user supplies a function or function object which will run in that new thread.

It's really as simple as:

boost::thread* thr = new boost::thread(MyFunc());
thr->join();

You can easily pass data to the thread by storing values inside the function object. And in the latest version of boost, you can pass a variable number of arguments to the thread constructor itself, which will then be passed to your function object's () operator.

You can also use RAII-style locks with boost::mutex for synchronization.

Note that C++0x will use the same syntax for std::thread.

Charles Salvia
  • 52,325
  • 13
  • 128
  • 140
  • 1
    IMHO The purpose of the Java concurrency libraries is to make multi-threading easier than plan Java Threads (which are based on pthreads) – Peter Lawrey Dec 26 '09 at 16:54
  • @PeterLawrey What's wrong with pthreads? Unless you were talking about concurrent collections in Java, then yeah those are impossible in pthreads. – IgorGanapolsky Jun 01 '16 at 18:22
  • 1
    @IgorGanapolsky nothing wrong with pthreads. I was making the point that comparing Boost with Java threads is not the same as comparing Boost with java.util.concurrent which was added in 2006 and these are a lot easier. The parallelStream() API is much easier again. – Peter Lawrey Jun 01 '16 at 19:34
7

Performance wise I wouldn't really worry. It is my gut feeling that a boost/c++ expert could write faster code than a java expert. But any advantages would have to fought for.

I prefer Boost's design paradigms to Java's. Java is OO all the way, where Boost/C++ allows for OO if you like but uses the most useful paradigm for the problem at hand. In particular I love RAII when dealing with locks. Java handles memory management beautifully, but sometimes it feels like the rest of the programmers' resources get shafted: file handles, mutexes, DB, sockets, etc.

Java's concurrent library is more extensive than Boost's. Thread pools, concurrent containers, atomics, etc. But the core primitives are on par with each other, threads, mutexes, condition variables.

So for performance I'd say it's a wash. If you need lots of high level concurrent library support Java wins. If you prefer paradigm freedom C++.

deft_code
  • 57,255
  • 29
  • 141
  • 224
4

If performance is an issue in your multithreaded program, then you should consider a lock-free design.
Lock-free means threads do not compete for a shared resource and that minimizes switching costs. In that department, Java has a better story IMHO, with its concurrent collections. You can rapidly come up with a lock-free solution.
For having used the Boost Thread lib a bit (but not extensively), I can say that your thinking will be influenced by what's available, and that means essentially a locking solution.
Writing a lock-free C++ solution is very difficult, because of lack of library support and also conceptually because it's missing a memory model that guarantees you can write truly immutable objects.

this book is a must read: Java Concurrency in Practice

Bokeh
  • 1,013
  • 7
  • 9
1

If you're targeting a specific platform then the direct OS call will probably be a little faster than using boost for C++. I would tend to use ACE, since you can generally make the right calls for your main platform and it will still be platform-independent. Java should be about the same speed so long as you can guarantee that it will be running on a recent version.

tloach
  • 8,009
  • 1
  • 33
  • 44
  • 2
    Boost.thread is faster than ACE for the sole reason that boost uses templates. Both boost and ACE make use of the same OS calls. Boost's compiled code, however, is very near what you would write using native pthreads. While ACE has to crawl through layers of abstraction before it touches native OS primitives. Java would have a similar issue but the JVM is able to remove most (all?) of abstraction costs. – deft_code Nov 18 '09 at 21:56
  • Don't forget that ACE focuses on cross platform communication and adds a lot of higher level abstractions like the Reactor/Proactor framework. So from that standpoint it may be preferred over boost. – count0 Aug 27 '11 at 20:46
0

In C++ one can directly use pthreads (pthread_create() etc) if one wanted to. Internally Java uses pthreads via its run-time environment. Do "ldd " to see.

Noone Special
  • 1