C ++ 11 is equivalent to increasing shared_mutex

Question

Is there a C ++ 11 equivalent for boost::shared_mutex . Or another solution to handle the situation with multiple readers / single writers in C ++ 11?

Answer 1

I tried, but could not get shared_mutex in C ++ 11. It was proposed for a future standard. Offer here .

Edit : For C ++ 14, a revised version (N3659) was adopted .

Here is the implementation:

http://howardhinnant.imtqy.com/shared_mutex

http://howardhinnant.imtqy.com/shared_mutex.cpp

Answer 2

Simple ... There is no one. There is no standard C ++ read-write implementation.

But you have several options.

• You are left on your own devices to create your own read / write mechanism.
• Use a platform implementation such as Win32 , POSIX, or Boost , as you mention.
• Don't use it at all - use mutex , which already exists in C ++ 11.

Transitioning C # 1 and implementing your own is a terrible undertaking, and you can call your code with the race conditions if you do not understand it correctly. There is a reference implementation that can facilitate the task.

If you need platform-independent code or don’t want to include any additional libraries in your code for something as simple as a read / write lock, you can throw # 2 out of the window.

And in # 3 there are a couple of caveats that most people don't understand: using read-write locks is often less efficient and has more complicated code to understand than the equivalent implementation using a simple mutex. This is due to the additional bookkeeping that needs to be done behind the scenes of implementing read-write locks.

---

I can only present you your options, indeed, you should weigh the costs and benefits of each and choose which works best.

---

Edit: C ++ 17 now has a shared_mutex type for situations where the benefits of having multiple parallel readers outweigh the cost of shared_mutex performance in itself.

Answer 3

No, for C ++ 11 there is no equivalent for boost::shared_mutex .

Read / write locks are supported in C ++ 14 or later:

• C ++ 14 added std::shared_timed_mutex
• C ++ 17 added std::shared_mutex

The difference is that std::shared_timed_mutex adds additional synchronization operations. It implements the SharedTimedMutex concept , which is an extension of the simpler TimedMutex concept implemented by std::shared_mutex .

---

Keep in mind that acquiring a lock for a read / write mutex is more expensive than acquiring a regular std::mutex . As a result, a read / write mutex will not improve performance if you have frequent but short read operations. It is better suited for scripting, as read operations are frequent and expensive. To quote a post by Anthony Williams :

The cost of locking shared_mutex is higher than the cost of locking plain std :: mutex, even for reader threads. This is a necessary part of the functionality --- there are more possible shared_mutex states than a mutex, and the code should handle them correctly. This cost is included both in the size of the object (which the implementation and my POSIX implementation includes as a simple mutex and condition variable), as well as when locking and unlocking an operation.

In addition, shared_mutex is a point of contention, and therefore scalable. Locking shared_mutex necessarily changes the state of the mutex, even to block reading. Therefore, the cache line containing the shared_mutex state must be transmitted depending on which processor is executing the lock or unlock operation.

If you have many threads that perform frequent short read operations, then in a multiprocessor system this can lead to a large amount of ping-pong cache, which will significantly affect system performance. In this case, you can also adopt a simpler design simply by using a simple mutex, as readers are essentially serialized anyway.

If reading is not frequent, then there is no claim, so you don’t have to worry about compatible readers, and a simple mutex for this scenario is enough anyway.

If the read operations take a lot of time, then the consequence of this statement is less noticeable, since it is overshadowed by the time spent while holding the read lock. However, the execution of labor-intensive operations while fixation is the smell of design.

In the vast majority of cases, I think there are better alternatives to shared_mutex. It could be a simple mutex, atomic support for shared_ptr, the use of a carefully designed parallel container, or something else, depending on the context.