[boost] Re: shared_ptr on ppc?

From: Marshall Clow (marshall_at_[hidden])
Date: 2005-04-07 11:22:38

Miro wrote:
>In article <004e01c53ac9$35901640$6601a8c0_at_pdimov>,
>  "Peter Dimov" <pdimov_at_[hidden]> wrote:
>
>  > or something like that. Post-release. The current code is good (and risky)
>  > enough. :-)
>
>My understanding from having spoken to several Apple engineers whom I consider
>knowledgeable on this topic is that it's a very bad idea to write 
>assembly code
>to perform atomic operations on the PPC. There is a variety of CPU-specific
>idiosyncracies that make it very difficult to write such code 
>correctly. As you
>might imagine, writing such code not quite correctly leads bugs that are very
>hard to track down.
>
>This recommendation is explicit in Apple's documentation at
><http://developer.apple.com/technotes/tn/tn2006.html>:
>
>"Do not use the PowerPC instructions Load Reserved  (lwarx) and Store
>Conditional  (stwcx) to implement atomicity in your preemptively threaded
>application. As described in DTS Technote 1137 Disabling Interrupts on the
>Traditional Mac OS, these instructions are non-portable and are tricky to use
>correctly across the full spectrum of PowerPC  implementations."

A couple of posters have referred to this as "smells-like-FUD", and 
"fails to state
any technical reasons".  To me, that sounds like denial.

Apple has committed to provide routines that work on all PPC CPU that 
they ship. Why in the world would you choose not to use them, if they 
do what you need?

At 1:39 AM +0300 4/7/05, Peter Dimov wrote:
>On the one hand, when the OS developers say that their API should be 
>used, one should listen.
>
>On the other hand, none of the technical notes state a concrete 
>problem with lwarx/stwcx.
>
>I am inclined to think that the problems with hand-written 
>lwarx/stwcx. code are not caused by CPU-specific idiosyncracies, but 
>by memory visibility issues. Which we have taken care of. (Memory 
>visibility could be described as CPU-specific, of course.)

Basing your code on "I'm inclined to think that..."  does not sound 
like sound engineering practice to me.

If you check out TN 1137, you see an earlier version of the same warning:

>Important:
>  DTS recommends that developers avoid using the PowerPC Load 
>Reserved and Store Conditional  instructions. There are two reasons 
>for this.  Firstly, these instructions are inherently 
>processor-specific and reduce the portability of  your code. 
>Secondly, the behavior of these  instructions varies between PowerPC 
>CPU types. Accommodating all these variations is tricky. These 
>instructions do not provide much utility beyond that provided by the 
>Open Transport and  DriverServicesLib atomic routines, and Apple 
>ensures that these atomic routines are updated to  do the right 
>thing in all cases.

If I was writing this code, I would not want to take on the burden of 
research, testing, and ongoing maintenance that this implies. 
Certainly "It works fine on my machine" is not sufficient, given 
these warnings.  Off the top of my head, I would want to test against 
the 601, 603, 603e, 604, G3 (several revisions), G4 (several 
revisions) and G5.

Apple has the advantage here, in that the code only has to run on a 
single CPU type - the one in the machine. [ They can (and probably 
do) have different routines for different CPUs, but only one gets 
burned into the ROMs that come with the machine. ] A routine that 
comes with boost has to deal with all the CPUs that Apple has shipped 
(+ future ones).
-- 
-- Marshall
Marshall Clow     Idio Software   <mailto:marshall_at_[hidden]>
It is by caffeine alone I set my mind in motion.
It is by the beans of Java that thoughts acquire speed,
the hands acquire shaking, the shaking becomes a warning.
It is by caffeine alone I set my mind in motion.