Quote:Original post by asp_

Quote:
I understand that if thread A reduces the counter to 0 and thread B tries to access the object while it is being destroyed by thread A. Is that the only problem or can the reference count in the shared_ptr actually screw up and either create a resource leak or prematurely reduce the reference count to 0?

This shouldn't really ever happen. Generally speaking there is no race condition for the reference counter as the increase and decrease operation is implemented in an atomic fashion.

Quote:Original post by asp_
The reset function however probably isn't protected as it operates on the object pointer and on the reference counter pointer.

Quote:Original post by fpsgamer

// Custom deleter function objectstruct CustomDeleter{     operator()(FILE* fp)     {        fclose(fp);     }};...// Create a shared_ptr representing a resourceshared_ptr<FILE> myFileHandle( fopen("MyFile.txt", "r"), CustomDeleter());

Quote:
There is no requirement that the reference count be implemented in an atomic fashion. For example the implementation of boost::shared_pointer explicitly doesn't synchronize the reference count. What reason do you have to believe that std::tr1::shared_ptr does?

boost/shared_ptr.hppmember of shared_ptrboost::detail::shared_count pn;    // reference counter

boost/detail/shared_count.hppmember of shared_countsp_counted_base * pi_;

boost/detail/sp_counted_base.hppincludes sp_counted_base_w32.hpp

boost/detail/sp_counted_base_w32.hppmember of sp_counted_base    long use_count_;        // #shared    long weak_count_;       // #weak + (#shared != 0)    void release() // nothrow    {        if( BOOST_INTERLOCKED_DECREMENT( &use_count_ ) == 0 )        {            dispose();            weak_release();        }    }

boost/detail/interlocked.hpp# include <windows.h># define BOOST_INTERLOCKED_INCREMENT InterlockedIncrement

Quote:Original post by loufoque
shared ownership, which shouldn't even happen in a normal program, unless as a low-level implicit sharing optimization.

Quote:Original post by asp_
I never said anything about TR1.

Quote:Original post by asp_
I specifically said to examine the detail space of boost. Just because you couldn't look it up yourself I've done it for you:

Quote:Original post by asp_
Oh my god. And look the GCC version does it as well.. and every other version... Do you realize how completely useless the shared_ptr would be without atomic reference count updates? Asynchronous operations would be completely impossible under more than one thread.

• 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

//--- Example 4 ---// thread Ap3 = p2; // reads p2, writes p3// thread B// p2 goes out of scope: undefined, the destructor is considered a "write access"

Quote:Original post by Red Ant
Any reference count synchronization problems with shared_ptr can easily be overcome by giving each thread its own shared_ptr instance. That way you're practically guaranteed that the reference count is always correct and the d'tor of the shared object is only run once and only by one thread.

Quote:Original post by loufoque
IMO shared_ptr is pure evil and should not be used.
It is only to manage shared ownership, which shouldn't even happen in a normal program, unless as a low-level implicit sharing optimization.
A good C++ program shouldn't use pointers at all, but only values and weak references.

Quote:Original post by fpsgamer
Lets say thread A passes the shared_ptr to another function by value (read/write access) when thread B terminates (write access).

Voila, undefined behavior.