You have two basic choices with a distant third. Everything else is not really advisable in my opinion right now. You can use Pthreads (and Boost::Thread) if you want to do 100% of the work yourself. You will have to write your own barriers and reductions, generate thread-local storage, and generally do all the heavy lifting. With all that work, comes all of the control you could want.
OpenMP gets rid of most of these problems by hiding most of the details. If you need to do both task parallelism and worksharing, you'll need a more modern implementation. GCC is coming along, but I haven't compared its completeness or performance to the Intel compiler in a long time. The Intel compiler's OpenMP implementation is traditionally pretty good. With OpenMP you get parallel loops, tasks, atomic/master/single regions for free which seem to cover 99% of scientific computing needs (where that means PDE and ODE simulation and linear algebra). There are lots of libraries (like the Intel MKL) that use/cooperate with OpenMP, so that's an advantage, too. With OpenMP 4.0, you get offload to accelerators, though I think that Intel is the only one supporting that and only for Xeon Phi.
TBB, while now open sourced, is a much less used and not standardized. That being said, it is very powerful, has many OpenMP-like constructs, and is very C++y. However, if you try to share your TBB code with anyone, they may not be able to help you since it's much less familiar.
All of the other things I can think of have less adoption, are not robust, have poor programmability, or have poorer performance. My list for that includes OpenCL (on the CPU not GPU), Haskell, Julia, Chapel, X10, UPC, Co-Array Fortran, Python Multiprocessing, etc., etc.
Unless you're a language nerd who likes explore new languages for fun, I wouldn't recommend writing a scientific app that needs to see the light of day, have performance, and use a library in anything but C/C++/Fortran with OpenMP for threading. When it comes to traditional scientific computing, there are too many libraries out there that expect a C/threads interface to waste your time reinventing the wheel.