shared_ptr Thread-Safe

1.9 Re-discussion on thread safety of shared_ptr

Although we borrow shared_ptr to implement thread-safe object deallocation, the shared_ptr itself is not 100% thread-safe. its reference count itself is secure and unlocked, but the object's read-write is not, because the shared_ptr has two data members, and the read-write operation cannot be atomized. According to the document 11,SHARED_PTR, the thread safety level and the built-in type, the standard storage device, the std::string, are:

A shared_ptr object entity can be read concurrently by multiple threads;

Two shared_ptr object entities can be written at the same time by two threads, and the "destructor" is a write operation;

If you want to read and write the same shared_ptr object from multiple threads, you need to lock it.

Note that the above is the thread-safe level of the shared_ptr object itself, not the thread-safe level of the object it manages .

To access the same shared_ptr in multiple threads at the same time, the correct approach is to protect it with a mutex:

1. Mutexlock Mutex; No Need for ReaderWriterLock
2. shared_ptr<Foo> globalptr;
3. Our mission is to safely pass the globalptr to doit ()
4. void doit (const shared_ptr<Foo>& pfoo);

Globalptr can be seen by multiple threads, then its read and write needs to be locked. Note that we do not have to use a read-write lock, but only the simplest mutex, which is for performance reasons. Because the critical section is very small, it does not block concurrent reads with mutexes.

In order to copy the globalptr, it needs to be locked when it is read, i.e.:

1. void Read ()
2. {
3. shared_ptr<Foo> localptr;
4. {
5. Mutexlockguard lock (mutex);
6. Localptr = globalptr;//Read globalptr
7. }
8. Use localptr since here, read and write Localptr no need to lock
9. Doit (localptr);
10. }

Locks are also added when writing:

1. void Write ()
2. {
3. shared_ptr<foo> Newptr (New Foo);//Note that objects are created outside the critical section
4. {
5. Mutexlockguard lock (mutex);
6. Globalptr = newptr;//write to Globalptr
7. }
8. Use newptr since here, read and write Newptr no need to lock
9. Doit (newptr);
10. }

Note that the above read () and write () do not have access to globalptr outside the critical section, but instead use a shared_ptr local copy on the stack that points to the same Foo object. As soon as this local copy exists, shared_ptr does not have to be copied as a function parameter, with reference to const as the parameter type. Note also that the above new Foo is executed outside the critical section, which is usually better than writing globalptr.reset (new Foo) in the critical section, because the critical section length is shortened. If the object is to be destroyed, we can certainly execute globalptr.reset () in the critical section, but this tends to cause the object's destruction to occur within the critical section, increasing the length of the critical section. An improvement is to define a localptr as above, using it to swap (swap ()) with the globalptr in the critical section, which guarantees that the destruction of the object is deferred beyond the critical section. Exercise: In the Write () function, globalptr = newptr; This sentence might destroy the Foo object pointed to by the original globalptr in the critical area, and try to remove the destruction behavior from the critical section.

Why multithreading read-write shared_ptr to lock?

shared_ptr Thread Safety Analysis

shared_ptr Thread-Safe