Re: [boost] shared_ptr/weak_ptr and thread-safety

From: Michael Ost (most_at_[hidden])
Date: 2003-05-22 13:25:58

Forgive me if I am jumping in inappropriately but if this is of
interest... I recently started using shared_ptr to solve a problem in my
app, and found that I needed to set BOOST_DISABLE_THREADS
since I don't need the thread safety built in to shared_ptr. The app
handles that itself.

But this sledgehammer approach means I can't use the boost thread
classes in the same app, which I was considering doing.

I wouldn't mind another BOOST_xxx precompiler setting to determine
thread usage in shared_ptr, since the designers appear uninterested in
the parameterization solution.

Cheers... mo

On Thu, 2003-05-22 at 10:41, Alexander Terekhov wrote:
> <Forward Inline>
> 
> -------- Original Message --------
> Message-ID: <3ECD0AC9.69B39C93_at_[hidden]>
> Date: Thu, 22 May 2003 19:37:13 +0200
> From: Alexander Terekhov <terekhov_at_[hidden]>
> Newsgroups: comp.programming.threads
> Subject: shared_ptr/weak_ptr and thread-safety
> References: ... <3ECD0007.14DC5665_at_[hidden]>
> 
> Joseph Seigh wrote:
> > 
> > Alexander Terekhov wrote:
> > >
> > > Okay. How about 'super_thread_safe_shared_ptr<>'? ;-)
> > >
> > > Seriously, "atomic_ptr" doesn't really convey what it is. You might
> > > also want to consider making it either blocking [maximum portability;
> > > but pretty much useless ;-)] or non-blocking (with "emphemeral" stuff
> > > and/or whatever tricks). Oder?
> > >
> > 
> > Well, Detlefs calls it lock-free reference counting.  But Boost
> > would probably call what they're doing with thread-safe reference
> > counting lock-free also, and they are not the same.  
> 
> They don't call it "lock-free". Here's what they say:
> 
> http://std.dkuug.dk/JTC1/SC22/WG21/docs/papers/2003/n1450.html
> (A Proposal to Add General Purpose Smart Pointers to...)
> 
> "....
>  The count structure C has the following members:
> 
>  Virtual table pointer (C is polymorphic); 
>  Use count; 
>  Weak count; 
>  Mutex (for multithreaded builds); 
>  Original pointer passed to the constructor; 
>  Deleter.
>  ....
>  The mutex presents another target for platform-specific 
>  optimizations. On Windows, we have been able to use a simple 
>  one-word spinlock instead of a 6 word CRITICAL_SECTION. The 
>  portable architecture of the implementation that abstracts 
>  the mutex concept in a separate class prevents further 
>  optimizations, like reusing the use count word as the 
>  spinlock, or using the Windows API InterlockedIncrement, 
>  InterlockedDecrement, and InterlockedCompareExchange 
>  primitives to attempt to eliminate the mutex altogether. 
>  Nevertheless, we believe that such optimizations are 
>  possible.
>  ...."
> 
> >                                                      The meaning
> > of atomic w.r.t java pointers is or should be well understood, so
> > atomic something would be indicated.  Also, it wouldn't preclude
> > a non lock-free implementation, though you would lose the bemefits
> > of lock-free.
> > 
> > Maybe atomic_shared_ptr.
> 
> Well, I'd love to have a policy-based framework that would 
> allow me to specify the *thread-safety policy*:
> 
>   thread_safety::unsafe
> 
>     "naked" count(s)
> 
>   thread_safety::basic
> 
>     pthread_refcount_t stuff (<http://tinyurl.com/cewa>)
> 
>   thread_safety::strong
> 
>     your "atomic" stuff
> 
> or something like that. Note that for the blocking stuff, one 
> would REALLY want to have some support for priority protocols 
> (priority protection or priority inheritance) to fight the 
> "unbounded priority inversion" problem in the "realtime" apps.
> 
> regards,
> alexander.
> 
> --
> http://terekhov.de/pthread_refcount_t/draft-edits.txt
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost