Re: [boost] Fw: [atomic] review results

Subject: Re: [boost] Fw: [atomic] review results
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-11-08 07:17:10

Helge Bahmann wrote:
> On Tuesday 08 November 2011 12:30:58 you wrote:
>
> > > well gcc certainly follows the recommendation of the
> > > standard by making the *lock-free* atomics both address-
> > > free and free from process state, I don't read the standard
> > > as suggesting (or even requiring) anything for emulated
> > > atomics
> >
> > in my reading the sentence `The implementation should not
> > depend on any per- process state' is not restricted to lock-
> > free atomics, but i am not a native speaker and i could be
> > wrong.
>
> neither am I but from the following full excerpt as quoted by
> Peter Dimov:
>
> [ Note: Operations that are lock-free should also be address-
> free. That is, atomic operations on the same memory location
> via two different addresses will communicate atomically. The
> implementation should not depend on any per-process state. This
> restriction enables communication by memory that is mapped into
> a process more than once and by memory that is shared between
> two processes. —end note ]
>
> I think that "address-free" clearly applies only to "lock-
> free", and if something is not "address-free" then the point
> whether it can be used interprocess is kind of moot as it is
> most certainly not going to be mapped at the same address (if
> you consider numerically identical addresses in different
> spaces to be the same at all).

My reading suggests that everything is related to lock-free operations.  This is evident in the second sentence, since it begins with "that is", which is introducing clarification of the first sentence.  The third sentence is stating a desired goal which is necessary for the sharing described in the last sentence.  The question, then, is whether the last two sentences are specifically related to lock-free operations or are intended to apply more generally.  While there is room for another interpretation and contrary intention, the fact that this is structured as a single note suggests it is a cohesive discussion all related to the thesis statement in the first sentence.  I, therefore, conclude that the entire note is about lock-free operations.

Since there is confusion, it would be appropriate to file a DR on the note to get clarity.  However, since it is non-binding text, I'm not sure how the committee will handle it.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer                     using std::disclaimer;
Dev Tools & Components
Susquehanna International Group, LLP  http://www.sig.com





________________________________

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.