From: "terekhov"
--- In Boost-Users@y..., "Peter Dimov"
wrote: OK, I did, but I still have trouble translating this into a specific problem with the shared_ptr code. Do you have an example?
Given:
- a mutable shared object OBJ; - two threads THREAD1 and THREAD2 each holding a private smart_ptr object pointing to that OBJ.
----
t1: THREAD1 updates OBJ (thread-safe via some synchronization) and a few cycles later (after "unlock") destroys smart_ptr;
t2: THREAD2 destroys smart_ptr WITHOUT doing any synchronization with respect to shared mutable object OBJ; OBJ destructors are called driven by smart_ptr interface...
Yes, I see it now, thanks. I'm still not sure whether this is a shared_ptr problem... One might argue that the destructor of a mutable object is logically an "update" and therefore should be mutex-protected as the rest of the operations on OBJ unless it's guaranteed to not compete with them. On the other hand placing a memory barrier in shared_ptr will probably be a good thing from user point of view; but I don't want to make shared_ptr depend on pthreads. -- Peter Dimov Multi Media Ltd.