Miro wrote:
In article <004e01c53ac9$35901640$6601a8c0@pdimov>, "Peter Dimov" <pdimov@mmltd.net> 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@idio.com> 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.