Subj : Re: A question about atomic_ptr
To   : comp.programming.threads
From : Joe Seigh
Date : Sun Apr 10 2005 08:38 am

On Sun, 10 Apr 2005 12:49:22 +0300, Peter Dimov <pdimov@gmail.com> wrote:

> atomic_ptr (atomic-ptr-plus.sf.net), as most of you know, is Joe Seigh's
> strongly thread safe reference-counted smart pointer.
>
> My understanding (based on atomic_ptr.txt) is that it is intended to be used
> in the GC phase of the reader/writer problem as follows:
>
> atomic_ptr<X> px; // shared object
>
> atomic_ptr<X> read()
> {
>     return px; // competing
> }
>
> void write()
> {
>     lock();
>
>     atomic_ptr<X> tmp( new X( *px ) );
>
>     // update *tmp
>
>     px = tmp; // competing
>
>     unlock();
> }
>
> boost::shared_ptr can't be used in the above manner because of the two
> competing accesses that violate its "basic thread safety" requirement.
>
> However (again, if my understanding is correct), all atomic_ptr read
> accesses need to have acquire semantics, while shared_ptr read accesses need
> not. (local_ptr aside for a moment.)

atomic_ptr wouldn't be very useful or convenient without acquire and
release semantics.  shared_ptr doesn't need them since acquire and
release semantics are provided by the mechanism used to ensure
"ownership" of shared_ptr's.

>
> My question is:
>
> Can I get the best of both worlds by providing the following two methods in
> shared_ptr:
>
> template<class T> class shared_ptr
> {
> // ...
>
>     shared_ptr<T> copy() const;
>     void replace( shared_ptr<T> const & pt );
> };
>
> with the guarantee that competing accesses to 'copy' and 'replace' work (but
> other competing accesses are still disallowed in order to avoid an acquire
> except in 'copy')?
>

You could, though you've in effect merged atomic_ptr and local_ptr together.
As a practical matter, I'd think you'd want some mechanism to distinguish
between shared global pointers and non-shared local pointers.

-- 
Joe Seigh

.