Is Boost Shared_Ptr <Xxx> Thread Safe

Is boost shared_ptr XXX thread safe?

From the boost documentation:

shared_ptr objects offer the same
level of thread safety as built-in
types. A shared_ptr instance can be
"read" (accessed using only const
operations) simultaneously by multiple
threads. Different shared_ptr
instances can be "written to"
(accessed using mutable operations
such as operator= or reset)
simultaneously by multiple threads
(even when these instances are copies,
and share the same reference count
underneath.)

Any other simultaneous accesses result in undefined behavior.

So your usage is not safe, since it uses simultaneous read and write of m_res. Example 3 in the boost documentation also illustrates this.

You should use a separate mutex that guards the access to m_res in SetResource/GetResource.

shared boost::shared_ptr variable is thread safe?

No. There is data race. One thread writes g_a, another thread reads g_a. Sync needed.

why is std::shared_ptr using atomic cpu operations

Any instance of shared_ptr is multi-thread safe. The data it points to is not multi-thread safe. See this.

The atomic instructions, if properly applied (protection done in the same order by competing thread access) is one way to implement thread safety. Another way is by use of mutexes.

See a similar question for BOOST: Is boost shared_ptr xxx thread safe?

Is it safe to return by value a shared_ptr that is guarded by mutex?

If by "safe" you mean you won't get data races on a, then yes. It is exactly as you say.

However, it won't protect further accesses to *a (or *clone_a()), as you probably know. I'm not sure, why is the method called "clone", as it doesn't clone anything.

Thread safety of multiple-reader/single-writer class

This is an interesting use of shared_ptr to implement thread safety.
Whether it is OK depends on the thread-safety guarantees of
boost::shared_ptr. In particular, does it establish some sort of
fence or membar, so that you are guaranteed that all of the writes in
the constructor and insert functions of set occur before any
modification of the pointer value becomes visible.

I can find no thread safety guarantees whatsoever in the Boost
documentation of smart pointers. This surprizes me, as I was sure that
there was some. But a quick look at the sources for 1.47.0 show none,
and that any use of boost::shared_ptr in a threaded environment will
fail. (Could someone please point me to what I'm missing. I can't
believe that boost::shared_ptr has ignored threading.)

Anyway, there are three possibilities: you can't use the shared pointer
in a threaded environment (which seems to be the case), the shared
pointer ensures its own internal consistency in a threaded environment,
but doesn't establish ordering with regards to other objects, or the
shared pointer establishes full ordering. Only in the last case will
your code be safe as is. In the first case, you'll need some form of
lock around everything, and in the second, you'll need some sort of
fences or membar to ensure that the necessary writes are actually done
before publishing the new version, and that they will be seen before
trying to read it.

Is there a C++ smart pointer that could wrap up an object to make it thread safe?

if there is a smart pointer that could take in any class in its template and then any operations done with such pointer would result in a thread-safe operation.

No, there is no such smart pointer in the C++ standard.

Unhandled exception exception in boost shared_ptr destructor

And this crash is random and not easily reproducible.

Your program is experiencing some form of memory corruption. I believe my previous post would be useful about how to identify memory corruption using WinDBG/Pageheap on Windows platform.

https://stackoverflow.com/a/22074401/2724703

edx value is here 0x00000752. that is causing the access violation.

This indicates that, your are trying to access NULL pointer memory(with offset of +1874/0x752 byte). There could be several reason for this and it is not possible to understand all by looking at your current information.One of the reason could be your program is multi-threaded and some other thread is trying to release this shared memory concurrently with this thread.

EDIT

Following information can be found from boost documentation.

shared_ptr objects offer the same level of thread safety as built-in
types. A shared_ptr instance can be "read" (accessed using only const
operations) simultaneously by multiple threads. Different shared_ptr
instances can be "written to" (accessed using mutable operations such
as operator= or reset) simultaneosly by multiple threads (even when
these instances are copies, and share the same reference count
underneath.)

Any other simultaneous accesses result in undefined behavior.

Does it risk if use c++ std::unordered_map like this?

I'm not sure if I can use insert like this.

Yes, you can, because operator[]

Returns a reference to the value that is mapped to a key equivalent to key, performing an insertion if such key does not already exist.

Your value_type is std::unordered_set which is default constructible, so there is no problem.

After initialization, the map will be read only in multi-thread

Here also you are safe, because according to the containers documentation

All const member functions can be called concurrently by different threads on the same container.

so if you are only reading the values without modifying them, it is OK. You could even perform write operations if you could guarantee that different threads are accessing different elements in your container.

---

Related Topics