Re: [boost] Re: shared_ptr/weak_ptr and thread-safety
Alexander Terekhov said: > > "William E. Kempf" wrote: > [...] >> Not specifying the exact width >> of various types is not really something that I think most people >> would classify as "brain damaged." > > That's not the only problem with MS-interlocked API. For example, for > DCSI and DCCI things, all you need is "hoist-load" and "sink-store" > barriers; a "full" acquire/release is an overkill, so to speak. Also, > for "basic" thread-safe reference counting, you really want to have > "naked" increments and either "naked" decrements [for the immutable > stuff] or decrements with "acquire-if-min"/"release-if-not-min" > memory synchronization semantics. I'd agree with that, but that's not what you said in the thread to defend the "brain damaged" remark. Further, even this wouldn't classify it as "brain damaged" to me, because what they give can be used correctly and successfully for some use cases. "Brain damaged" implies it can't be used at all. It's too derogatory to be used for anything less, and you throw the term around very frequently. >> Now, can you provide documentation for the above, including >> preconditions, postconditions, etc. for each method? > > Do you mean refcount<>'s methods? atomic<> stuff? refs<>-thing? All of it. > A "man-pages"-like specification for plain C version of optionally > non-blocking pthread_refcount_t without parameterization (I mean > thread-safety and counter type) can be found here: > > http://terekhov.de/pthread_refcount_t/draft-edits.txt Thanks. I'll take a look at it. -- William E. Kempf ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: shared_ptr/weak_ptr and thread-safety
Alexander Terekhov said: >> > P.S. ``Where's Bill?'' ;-) >> >> Please, drop the adversarial tone in your posts. > > I can't. Really. You can't, or you won't? The above could have been just as easily written as: P.S. Is Bill reading this? Even just removing the wink would have taken a lot of the "bite" out of your post. > >> It's rude at best. > > Sorry for that; well, try to not take it seriously. Should I not take anything you say seriously? >> I was on vacation, but I'm hardly ignoring any of this. I had an >> atomic class in Boost.Threads pre-review, but it was removed because >> it needed a lot more research and effort than I had time for in that >> release. I'm trying to track the efforts you've been doing in this >> area, but you scatter things so much with "see this link" type posts >> that it's difficult. > > Okay. Thanks. I'll see if this helps. >>If you can write a summary paper or even provide a base >> implementation with thorough documentation, I'd definately be >> interested. > > Well, I'm basically done with "introduction". Here we go: Inline> > > Original Message > Message-ID: <[EMAIL PROTECTED]> > Newsgroups: comp.programming.threads > Subject: Re: using atomic_ptr for a lock-free instance once algo? > References: ... <[EMAIL PROTECTED]> > > SenderX wrote: >> >> > The acquire/release semantic are associated with the external >> pointer load >> and store >> > actions as observed by the program. Nothing to do with the cas >> operations >> since >> > atomic_ptr's are atomic and are safe without them but would then be >> about >> as useful >> > as pre-JSR 133 references. >> >> Is that why Alex says that the server 2003 >> InterlockedCompareExchangeAcquire/Release API's are brain-damaged? > > MS interlocked stuff is totally brain-damaged because it *DOESN'T* > > 1. extend C99's with: > > atomic integer types having certain exact widths; > atomic integer types having at least certain specified widths; > atomic fastest integer types having at least certain specified > widths; atomic integer types wide enough to hold pointers to > objects; atomic integer types having greatest width. > >providing "interlocked" function like macros with various memory > synch semantics for atomic operations. > > 2. introduce a "plusified" version of with atomic integers >( would be a good name for it, probably). > > 3. introduce header that would provide a C++ >template covering scalar types (based on "certain", or "least", or > "fastest" integers as optionally specified template argument) via > atomic<> specializations ala numeric_limits<> ones. This hardly suffices as documentation, or even a summary paper. I'd also (as usual) take great exception to your use of the term "brain damaged", especially given your technical reasons. Not specifying the exact width of various types is not really something that I think most people would classify as "brain damaged." Now, can you provide documentation for the above, including preconditions, postconditions, etc. for each method? I'll get by if you can't, but documentation would be very useful. -- William E. Kempf ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: shared_ptr/weak_ptr and thread-safety
Alexander Terekhov said: > > Trevor Taylor wrote: > [...] >> Why wait? With so many people contributing to boost, why not introduce >> a pthread_refcount_t into into boost threads (or is there one >> already?), provide a default implementation equivalent to what >> shared_ptr does now, > > Nah. atomic<> based stuff would surely be much better than what > shared_ptr does now, I think. > >> and let the platform experts provide the optimal specialisations. > > http://groups.google.com/groups?selm=3EC4F194.2DA8701C%40web.de > (Subject: Re: Is this thread-safe on multi-processor Win32?) > > regards, > alexander. > > P.S. ``Where's Bill?'' ;-) Please, drop the adversarial tone in your posts. It's rude at best. I was on vacation, but I'm hardly ignoring any of this. I had an atomic class in Boost.Threads pre-review, but it was removed because it needed a lot more research and effort than I had time for in that release. I'm trying to track the efforts you've been doing in this area, but you scatter things so much with "see this link" type posts that it's difficult. If you can write a summary paper or even provide a base implementation with thorough documentation, I'd definately be interested. -- William E. Kempf ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: shared_ptr/weak_ptr and thread-safety
Alexander Terekhov wrote: > Peter Dimov wrote: >> >> Trevor Taylor wrote: >>> >>> Why wait? With so many people contributing to boost, why not >>> introduce a pthread_refcount_t into into boost threads (or is there >>> one already?), provide a default implementation equivalent to what >>> shared_ptr does now, >> >> We can't; shared_ptr uses a single pthread_mutex to protects its two >> counts. A naive pthread_mutex based pthread_refcount_t would result >> in two mutexes, one per count. > > Yeah. http://google.com/groups?q=PTHREAD_REFCOUNT_NONBLOCKING Something like that. Are you planning to implement a "real" pthread_refcount_t for, say, Windows and Linux/x86? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: shared_ptr/weak_ptr and thread-safety
Alexander Terekhov wrote: > Michael Ost wrote: > [...] >> I wouldn't mind another BOOST_xxx precompiler setting to determine >> thread usage in shared_ptr, ... > > Rather: http://google.com/groups?q=try+to+convince+Dimov+smart+policy Or for those that don't feel like following Alexander's links: "René Dalby Carlsen" wrote: [...] > The above sample does not work - what should I do instead? Try to convince Dimov that policy-based designs/interfaces aren't that bad; and that, in general, the stuff managed by smart pointers isn't necessarily process-wide/thread-shared stuff "by default"... like global heap, current working directory, etc. regards, alexander. -- "Yes, every user of shared_ptr that has BOOST_HAS_THREADS defined is burdened with the overhead of having a shared_ptr that works. :-) shared_ptr follows the standard library practice here; every user is burdened with a synchronized heap allocator, too." -- http://aspn.activestate.com/ASPN/Mail/Message/1263557 ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: shared_ptr/weak_ptr and thread-safety
Alexander Terekhov wrote: < 2 x Forward Inline > [snip] There's no COW semantics here. It's rather simple, really. Any operation that "updates" the use-count needs to be synchronized with respect to other readers/writers. The basic thread safety is pretty much the same stuff as POSIX's memory synchronization rules stated in 4.10/Base Definitions volume. Note that things like semas and pthread_refcount_t provide STRONG thread-safety (for themselves; from "OO" point of view, if you look at their interface); well, with some "exceptions"... please take a look at pthread_refcount_setvalue(). I'm a newbie, so this might seem a simple question: Wouldn't weighted reference counts eliminate around half the synchronization. This is because, AFAICT, the only time synchronization is needed is when a smart weighted pointer releases it's pointee, but not when it acquires a new pointee (because the reference count is gotten from the other, or source, smart weighted pointer). ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
