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

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-06-02 16:08:32

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. <copy&paste>

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: <Forward
> Inline>
>
> -------- Original Message --------
> Message-ID: <3EDB59F3.982399EB_at_[hidden]>
> Newsgroups: comp.programming.threads
> Subject: Re: using atomic_ptr for a lock-free instance once algo?
> References: ... <%aICa.21085$DV.25030_at_[hidden]>
>
> 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 <stdint.h> 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 <stdint.h> with atomic integers
>    (<stdint> would be a good name for it, probably).
>
> 3. introduce <atomic> header that would provide a C++ <atomic>
>    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