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: <[EMAIL PROTECTED]> > Date: Thu, 22 May 2003 19:37:13 +0200 > From: Alexander Terekhov <[EMAIL PROTECTED]> > Newsgroups: comp.programming.threads > Subject: shared_ptr/weak_ptr and thread-safety > References: ... <[EMAIL PROTECTED]> > > 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost