Ovanes Markarian writes:

Ok, just looking at the example will bring more light into your questions.

First non-safe scenario: // thread A p = p3; // reads p3, writes p

// thread B p3.reset(); // writes p3; undefined, simultaneous read/write

Either thread B is executed before thread A, then you assign empty shared

prior pointer deletion in thread B) OR thread A is executed before thread B,

pointer in thread A (to then a valid pointer

is assigned in B. Possible scenario here as well: Value of p3 is read, scheduler switches to thread B; deletes pointer owned by p3; switches back to thread A and assignes invalid pointer value to p (deletion of pointee can happen probably twice and it is also undefined what is in memory at the point of assignment and what will be written later on...) ... Ovanes Markarian

This should mean that shared_ptr is not at all thread safe, as in above race condition. I am not sure if this contradicts the quote 'shared_ptr objects offer the same level of thread safety as built-in types', it at least does not address the thread safety of the unique reference counting feature (which has no analog for 'normal' pointers). The atomic increment and decrement ref counting then only work for a shared const shared pointer: void g(boost::shared_ptr<const B> ptr) { //... } void f() { boost::shared_ptr<const B> ptr(new B); //give ptr to threads boost::thread thrd1(boost::bind(&g, ptr)); boost::thread thrd2(boost::bind(&g, ptr)); //fire and forget ptr.reset(); } However they finally end up in a dtor call which according to the documentation is an legal or illegal write operation.

gast128 wrote:

The atomic increment and decrement ref counting then only work for a shared const shared pointer:

No, the presence or absence of 'const' do not affect the thread safety of a piece of code.

void g(boost::shared_ptr<const B> ptr) { //... }

void f() { boost::shared_ptr<const B> ptr(new B);

//give ptr to threads boost::thread thrd1(boost::bind(&g, ptr)); boost::thread thrd2(boost::bind(&g, ptr));

//fire and forget ptr.reset(); }

This example is OK. You have three distinct shared_ptr variables, all named 'ptr' (one per thread). Despite them having the same name, they are still different objects, not shared among threads, so you can assign/reset/destroy them at will.

Ovanes Markarian wrote:

...

...

...

void g(boost::shared_ptr<const B> ptr) { //... }

void f() { boost::shared_ptr<const B> ptr(new B);

//give ptr to threads boost::thread thrd1(boost::bind(&g, ptr)); boost::thread thrd2(boost::bind(&g, ptr));

//fire and forget ptr.reset(); } This example is OK. You have three distinct shared_ptr variables, all named 'ptr' (one per thread). Despite them having the same name, they are still different objects, not shared among threads, so you can assign/reset/destroy them at will.

Yes, just in addition, your code would be broken, if g would expect a shared_ptr by reference, i.e. void g(boost::shared_ptr<const B>& ptr). Then all your threads would own the same shared_ptr instance and the thread in which runs the function f would reset the pointer which might be used by thrd1 or thrd2 and that might cause the scenario from the docs example.

I wouldn't think so in this case, since boost::bind makes a copy of the shared_ptr before it gets passed to g(). If the code used boost::bind(&g, boost::ref(ptr)), then there would be a race condition. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org ra

Ok thx all. Maybe it's after all in the documentation. One shared_ptr can be shared if there is read access only. Multiple instances of a shared_ptr pointing to the same pointee can be written to simultanesly. Something similar is to be found in the documentation. Wkr.

David Abrahams writes:

No, it's exactly "as threadsafe as int."

snip because of 'There's much more quoted text in your article than new. Prune quoted stuff.'

That sequence would not be safe with a naive reference-counted pointer that was totally unaware of thread safety.

'Inside COM' from Dale Rogerson suggests to make ref counting atomic (i.e. through InterLockedIncrement).

Ovanes Markarian wrote:

Ok, just looking at the example will bring more light into your questions.

First non-safe scenario: // thread A p = p3; // reads p3, writes p

// thread B p3.reset(); // writes p3; undefined, simultaneous read/write

Either thread B is executed before thread A, then you assign empty shared pointer in thread A (to prior pointer deletion in thread B) OR thread A is executed before thread B, then a valid pointer is assigned in B. Possible scenario here as well: Value of p3 is read, scheduler switches to thread B; deletes pointer owned by p3; switches back to thread A and assignes invalid pointer value to p (deletion of pointee can happen probably twice and it is also undefined what is in memory at the point of assignment and what will be written later on...)

Hi, all! I understand, that thread A could get an invalid pointer. But what if thread B did not reset p3, but rather reassign it? Assuming that I don't care if the reader gets the new pointee or the old one. I just wan't to assure that all dynamic objects would be deleted properly. // pre-thread boost::shared_ptr<const A> ptr(new A); // reader thread A boost::shared_ptr<const A> p1=ptr; // get the latest value p1->getSomeValue(); p1->getSomeOtherValue(); p1.reset(); // don't need that anymore // reader thread B boost::shared_ptr<const A> p2=ptr; // get the latest value p2->getSomeValue(); p2->getSomeOtherValue(); p2.reset(); // don't need that anymore // writer thread ptr.reset(new A); // look Ma! I've brought you something new! So is the substitution thread-safe? I think it could be, if the steps necessary to do that were taken in the following order: - setting new object's counter to 1 (atomicity irrelevant at this point) - switching internal pointer to point to the new object (atomic) - from now on, reader threads would get the new object - decrementing old object's counter (atomic) - the old object gets released and eventually deleted If it's not that way, would this template class help in the abovementioned use-scenario: template <class T> class SharedObject { public: typedef boost::shared_ptr<T> SharedPtr; SharedObject() : sharedPtr(new const SharedPtr(new T)) {} ~SharedObject() { delete sharedPtr; } SharedPtr get() { return *sharedPtr; } void set(T *httpLogFilter) { const SharedPtr *newSharedPtr=new SharedPtr(sharedObject); const SharedPtr *oldSharedPtr=sharedPtr; // there sould be a write membar here probably sharedPtr=newSharedPtr; // atomic substitution delete oldSharedPtr; } private: const SharedPtr *sharedPtr; }; PS Would any valid compiler rearrange isntructions is set() ? Thanks in advance for your help! -- View this message in context: http://www.nabble.com/shared_ptr-and-thread-safety-tf4223939.html#a12224610 Sent from the Boost - Users mailing list archive at Nabble.com.