Is It Smart to Replace Boost::Thread and Boost::Mutex with C++11 Equivalents

Is it smart to replace boost::thread and boost::mutex with c++11 equivalents?

There are several differences between Boost.Thread and the C++11 standard thread library:

• Boost supports thread cancellation, C++11 threads do not
• C++11 supports std::async, but Boost does not
• Boost has a boost::shared_mutex for multiple-reader/single-writer locking. The analogous std::shared_timed_mutex is available only since C++14 (N3891), while std::shared_mutex is available only since C++17 (N4508).
• C++11 timeouts are different to Boost timeouts (though this should soon change now Boost.Chrono has been accepted).
• Some of the names are different (e.g. boost::unique_future vs std::future)
• The argument-passing semantics of std::thread are different to boost::thread --- Boost uses boost::bind, which requires copyable arguments. std::thread allows move-only types such as std::unique_ptr to be passed as arguments. Due to the use of boost::bind, the semantics of placeholders such as _1 in nested bind expressions can be different too.
• If you don't explicitly call join() or detach() then the boost::thread destructor and assignment operator will call detach() on the thread object being destroyed/assigned to. With a C++11 std::thread object, this will result in a call to std::terminate() and abort the application.

To clarify the point about move-only parameters, the following is valid C++11, and transfers the ownership of the int from the temporary std::unique_ptr to the parameter of f1 when the new thread is started. However, if you use boost::thread then it won't work, as it uses boost::bind internally, and std::unique_ptr cannot be copied. There is also a bug in the C++11 thread library provided with GCC that prevents this working, as it uses std::bind in the implementation there too.

void f1(std::unique_ptr<int>);
std::thread t1(f1,std::unique_ptr<int>(new int(42)));

If you are using Boost then you can probably switch to C++11 threads relatively painlessly if your compiler supports it (e.g. recent versions of GCC on linux have a mostly-complete implementation of the C++11 thread library available in -std=c++0x mode).

If your compiler doesn't support C++11 threads then you may be able to get a third-party implementation such as Just::Thread, but this is still a dependency.

boost and c++11 thread compatibility

IMHO, your code is not threadsafe and hence should not work correctly under C++11. I think the problem is that the static variables rd and e are global variables but not protected (by mutex), so concurrent calls will race.

Presumably, you can make this code threadsafe by making those variables thread_local, but I have no experience.

C++11 equivalent to boost shared_mutex

I tried but failed to get shared_mutex into C++11. It has been proposed for a future standard. The proposal is here.

Edit: A revised version (N3659) was accepted for C++14.

Here is an implementation:

http://howardhinnant.github.io/shared_mutex

http://howardhinnant.github.io/shared_mutex.cpp

Is std::thread a drop in replacement for boost::thread?

Can I simply do a search replace and start using std::thread?

The current version of boost::thread has a few features that aren't in std::thread:

• join with timeout
• thread attributes
• interruption
• yield() and sleep() (deprecated)

See the boost documentation, where they are labelled EXTENSION. If you're not using any of those, then it should be a direct replacement.

As mentioned in the comments, older versions of boost::thread had a different behaviour on destruction. They would detach the thread if it was still joinable; std::thread and the current boost::thread call std::terminate instead.

Do I need to replace boost::bind with std::bind too or that is unnecessary?

That's not necessary; thread can be given any callable type. It's also not necessary to use bind at all, since it has a variadic constructor:

std::thread th(&myFunc, var1, var2);

replacing boost:: mutex

I had this problem in the past while mixing VS2012 and VS2010,
you really shouldn't work like this. it's a bug trap.

after two days of searching i have found this solution
http://connect.microsoft.com/VisualStudio/feedback/details/753623/fatal-error-c1001

please make sure you understand how to use pragma correctly.
i was able to compile and run!

hope this helps.

Boost::mutex is taking less time than without mutex for a program

In your example you lock the mutex in doSometask(), and, hence all the time only one thread will be running and it will finish the for loop before yielding to another task. Hence the program runs literally serial and no cache threshing occurs.

Without the lock, all threads will run when they get processor time, and assuming that the number of processors is significantly lower than 100 a lot of cache threshing will be going on on all levels (like Bo Persson wrote in the comments), and this will increase run-time.

A better way to measure the impact of the lock on run time would be (a) to run only as many threads as your computer has cores, so that cache threshing because of context switches are minimized, and (b), to put the lock into the ThreadPool::inc() method so that the synchronization happens more often.

As a bonus you could run the lock-free method properly by declaring p_size as std::atomic<int> (C++11) and see impact of synchronization based on mutexes versus the use of atomics.

is there a replacement of shared_memory_object in c++11

No. There is no notion of "Shared memory" in the standard. And thus no facilities to work with it.

---

Related Topics