[cpp-threads] Weak vs Strong Atomics

[Raul Silvera]

Lawrence Crowl wrote on 05/06/2007 11:18:12 PM:

> On 5/6/07, Raul Silvera <rauls at ca.ibm.com> wrote:
> > Lawrence Crowl wrote on 05/04/2007 02:14:49 PM:
> >
> > My main objection to your current proposal is that the C++ access to 
weak
> > atomics has a cumbersome syntax; is not much better than dropping down 
to
> > the C compatible layer. It begs the question as to why provide weak 
C++
> > atomics at all.
> 
> Well, as you point out, performance.  Do you really think writing
> atomic_fetch_add_relaxed(x,3) versus x.fetch_add_relaxed(3) will make
> a significant difference to programmers at this level?

Well, my point was that there should be access to weak operators from C++, 
without going down to the C-compatible level. The question of which syntax 
is more suitable than the other applies equally to weak atomics and strong 
atomics. From my point of view, if a syntax is not good enough for strong 
atomics, it isn't good enough for weak atomics either.

> > From my point of view strong atomics are just a prototyping
> > tool; we will strongly encourage programmers to use weak atomics, so 
we
> > would like to avoid complicated syntax that would conceal their 
existence
> > and discourage their use.
> 
> And your view is quite different from Herb's.

Yes, I think that Herb and I have agreed to disagree. It just comes down 
to having different constituencies, and different tradeoffs introduced by 
the underlying hardware. The compromise reached in Oxford is that we would 
have separate mechanisms to pander to these two groups, and we would tell 
each group to avoid using the mechanism that is not intended for them.

> Can you explain what you mean by "conceal their existence"?  Anything
> in the standard is by definition not concealed, so you must have 
something
> more specific in mind.

The concern is about easy access to them. For example, it would be nice if 
programmers could declare a weak atomic variable and then get a list of 
all functions available from their GUI. Again, it is the same argument 
that applied to strong atomics.

> > While I would prefer to have a single type, that type would have to be 
the
> > weak one, not the strong one. A single atomic type that provides SC on 
the
> > default operations and named member functions for more-weakly ordered
> > operations, would probably satisfy at least Nick's concerns.
> 
> That would require a type-based static analysis tool.  The free 
functions
> work better with grep.

grep would work fine as long as the names of the members are easily 
identifiable. Something like a namespace internal to the class to identify 
those member functions would have probably fit the bill (but I don't think 
that something like that exists in C++).

> > The new proposal using a derived type allows reasonable C++ access to 
weak
> > atomics while still satisfying Herb's requirements, so I think it is a
> > reasonable compromise.
> 
> Are you willing to live with being unable to get back to a weak atomic
> once an interface makes it strong?

No. I don't think that's on the table, but it wasn't discussed to great 
lengths in Oxford. I suspect some more discussion is needed to reach 
consensus on this issue. Such a guarantee isn't provided on your original 
proposal, and it isn't provided on this proposal either: in general, weak 
atomics passed to routines expecting strongs can be downcasted back to 
weak, right? Also, both weak and strong operations would be available by 
going down to the C-compatible layer.

> > The weak module cannot
> > interfere with the SC of the operations from the strong module; those 
will
> > still follow program order. The operations of the weak module may or 
may
> > not follow program order, but the program order of the weak module is
> > unknown to the strong module anyway.
> 
> Just what I wanted to hear.  Does anyone disagree with this statement?

I think there is some consensus on this issue now. With this out of the 
way, I personally don't see a strong motivation for moving from the 
compromise we had reached at Oxford.

--
Raúl E. Silvera         IBM Toronto Lab         Team Lead, Toronto 
Portable Optimizer (TPO)
Tel: 905-413-4188       T/L: 969-4188           Fax: 905-413-4854 
D2/KC9/8200/MKM

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.decadentplace.org.uk/pipermail/cpp-threads/attachments/20070508/91cb2007/attachment.html