Boost logo

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