views:

749

answers:

5

Hi,

How does 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.

thanks,

Ajay

A: 

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
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.
caspin
+7  A: 

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
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
+4  A: 

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++.

caspin
+4  A: 

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
A: 

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