In article <045D1135-E8F5-4BF3-82BE-813C835E31FC@lucena.com>, Steve Ramsey <steve@lucena.com> wrote:
In my (limited) research into the problem, I haven't been able to find any good examples of hand-rolled atomic ops that are mp-savvy, though I found plenty of dire warnings against making the attempt and numerous recommendations to use either the kernel-level or Carbon-level routines instead, depending on context.
I voiced my concern over hand-rolled assembly when this issue was brought up regarding the boost implementation, and I am going to voice it again. We do not have the resources to test this kind of a change on all the hardware we support, and the fact that a broken shared_ptr made it into a release just highlights this. I do not think that the intended performance improvement is worth sacrificing the quality of our libraries, and I don't see a way to maintain that quality if we make hardware-specific changes while not having the resources to test on all the supported hardware (including future hardware). My intent here is not to say "I told you so", but to point out that I consider this a pretty serious error, and that I think we should understand how it came to pass. Ben -- I changed my name: <http://periodic-kingdom.org/People/NameChange.php>