--- In Boost-Users@y..., "Peter Dimov"
From: "terekhov"
Just read the following write-up:
http://www.primenet.com/~jakubik/mpsafe/MultiprocessorSafe.pdf
"Relaxed multiprocessor memory models...."
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... Hmm... unless you imply that smart_ptr users should treat smart_ptrs as being thread-unsafe wrt object cleanup (destructors) and should somehow always lock/unlock (synchronize) mutable shared ref.counted objects in their destructors, the bottom line is: Atomicity of --/++ is just one of two issues with respect to correctness of ref. counting in the MT environment. Visibility of eventual updates for proper destruction (object clean-up) is another issue. Currently only lock/unlock could fulfill both requirements in a portable way. regards, alexander.