[cpp-threads] Re: Increment/decrement operators on atomics package

[Nick Maclaren]

Raul Silvera <rauls at ca.ibm.com> wrote:
> 
> I hope you're not suggesting to make t = t + 1 a RMW operation. There
> are many reasons why that is not feasible. The most we could do is
> outlaw it in favor of using named member functions to access/modify
> the variable, as Roger proposed on another note. However, if we were
> to do that, we probably should outlaw += and ++ operators as well.

Why isn't it FEASIBLE?  I agree with you that it's not a good idea,
but that isn't the same as it not being feasible.

> I believe it is simpler to teach the programmer that none of the implicit
> operations have RMW semantics, rather than have a subset of them be 
> RMW operations. From the programmer point of view, such a subset would
> be arbitrary. 

Hmm.  I have mixed views on that.  Provided that the subset is clearly
documented and natural, I don't see a major problem.  Nor do I see a
problem with your approach.

> If we keep the semantics of these operators as currently proposed, I
> foresee us getting into situations where we have to tell users:
> "there is a problem in your program, and to fix it replace x=x+1 with 
> x+=1".  I think that would be highly undesirable.

I can live with that.  Remember that these variables are flagged as
atomic, and a compiler can easily produce a list of all places where
such a variable was updated by a non-atomic operator.

> Also, note that RMW operations are orders of magnitude more expensive
> than regular accesses in pretty much all architectures. In some
> platforms they may require acquiring a lock. So I believe the programmer
> should make it explicit whether RMW semantics are required for each
> specific operation.

Come back System/360, all is forgiven :-)


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1 at cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679