|
Boost Users : |
From: terekhov (terekhov_at_[hidden])
Date: 2002-01-11 08:06:43
--- In Boost-Users_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: "terekhov" <terekhov_at_d...>
> > 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.
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net