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

[Boehm, Hans]

________________________________

	From: Raul Silvera [mailto:rauls at ca.ibm.com] 
	
	
	"Boehm, Hans" <hans.boehm at hp.com> wrote on 04/23/2007 07:39:33 PM:
	
	> > I consider it a valid concern, .  The choice, I think is 
	> > between the notational convenience of += and the education of 
	> > the users.  Given that using atomic will take substantial 
	> > education anyway, I fell on the side of notational 
	> > convenience.  If there is a consensus to remove the operator, 
	> > I think that the same reasoning applies to ++ operators.
	> > 
	> I actually have no idea which one would be more error prone for 
	> uneducated users.  My impression (backed up by very limited 
	> experience) is that the more naïve users may be surprised if you 
	> tell them that any of the above, even t = t + 1, is NOT atomic.  
	> Thus my inclination would be to follow the rule that any operations 
	> on atomics that reasonably could be atomic, should be.
	> 
	> Hans
	
	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. 
	 

I'm not suggesting making t = t + 1 atomic, whether it is feasible or not.  My assumption was that it is not, but I can see that that's arguable.

	 
	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.  
	 

I disagree, but this is probably a matter of taste.  It makes sense to me that individual operators on atomics are atomic, but combinations of them are not.  I was only arguing that no matter what we do, some naive users will be surprised.  I would expect the surprise factor to go up with the number of atomic operations that are not atomic.

	 
	
	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 remain unconvinced that this is a problem.  I would tell them that x = x + 1 invokes two separate atomic operations on x, and is hence not atomic.  += is a single operation that does provide atomicity.

	 
	
	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. 
	 

I'm with Peter, in that I don't think that's true under the current proposal.  In general, operators, since they guarantee sequential consistency, can be much more expensive than _relaxed accesses.  But it you write x = x + 1, I think you will need at least two fences on PowerPC, at least one of them a hwsync.  Does the "store conditional" for the atomic increment really add significantly to that cost?
 
On X86, I expect you will want to generate an atomic operation for the store in x = x + 1 in order to get SC.  As far as I can tell, that probably results in a negative cost for the atomicity in the increment.  I think the situation on Itanium is slightly less clear, but I'm also unsure whether the cost is positive or negative.  By my usual rules of thumb, they're approximately equivalent in cost.

--
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/20070427/55c5b693/attachment.htm