<Forward Inline> Joseph Seigh wrote: > > Alexander Terekhov wrote: > > > > Joseph Seigh wrote: > > > 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 fact that they consider and have done simplistic spin locks > speaks for itself.
Yeah. http://lists.boost.org/MailArchives/boost/msg44460.php > Also, they make a whole lot of distinctions > that don't translate very well into a threaded environment. > Their style of semantic definition with that pre and post internal > data state stuff doesn't work in multi-threading. I think it's fine. Please see the definitions of shared_ptr and weak_ptr thread "safeties" (below). > The one thing > you usually cannot reliably observe in multi-threading is internal data > state. You have to use other mechanisms to define semantics for > multi-threading. I don't think so. > To say nothing of their multiple attempts to > deal with data "ownership". It's why they have so many pointer > types, all compromised in some degree or other for some small > incremental benefit. ;-) > > > > > > 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. > > > > I'm never quite sure what "thread-safe" really means. It seems > to get used in different ways sometimes. thread_safety::unsafe means that *copying* AND all mutation operations on shared_ptr/weak_ptr copies (all pointing to the same object; "typed-null" including) shall be *synchronized*; otherwise, the behavior is undefined. Read-only stuff (copying aside) can be done concurrently. thread_safety::basic means that all "const" operations (including copying) can be done concurrently, but mutations shall be synchronized; otherwise, the behavior is undefined. thread_safety::strong means "do-whatever-you-want-and-don't- care-about-synchronization" (i.e. you can also mutate shared_ptr and weak_ptr objects *concurrently* without any synchronization because it's fully synchronized "internally"). > Atomic is easy to define. > It just means that you will only ever read some previously stored > value. The C and C++ standards already mandate that! Here's what C99 says, for example: "The lifetime of an object is the portion of program execution during which storage is guaranteed to be reserved for it. An object exists, has a constant address, and retains its last- stored value throughout its lifetime." regards, alexander. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
