On 23/08/05, Ben Artin <macdev@artins.org> wrote: In article <045D1135-E8F5-4BF3-82BE-813C835E31FC@lucena.com>, Steve Ramsey <steve@lucena.com> wrote: <snip> 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.
The testing failed. There should be a test that warns if a correct result occurs when it should fail. For example, my home grown atomic ops include a unit test that does this. See below for an example. It warns if an unprotected increment operation works safely.
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).
The performance improvement is definitely worth it on many platforms for many apps. Native atomic ops are often an order of magnitude faster. Though many os platforms will wrap such ops in lib call that is just as fast... is this what you're referring to rather than using a generic safe approach? Perhaps you should be able to "opt out" to a mutex implementation via a #define. matt. //-------------------------------------------------- <snip> #define X86_64_GCC #include <synch/atomic_op.hpp> void synch_test_001() { static int global_count = 0; int number_of_threads = 10; static int inner_loop = 10000000; ZOMOJO_WORKER_THREAD_BEGIN( inner_loop ) global_count = global_count + 1; // unsafe naked increment of shared int ZOMOJO_WORKER_THREAD_END( number_of_threads ) BOOST_MESSAGE( "orderly progression = " << inner_loop * number_of_threads ); BOOST_MESSAGE( "conccurrent progression from this run = " << global_count ); // Warning will be generated if concurrency is not useful // If this warning is generated then the validity of the other tests for concurrency testing // is questionable. That is, if lots of threads can increment a shared variable with no // harmful consequences then testing locking and other concurrency strategies is not going // to test concurrency usefully. The further tests should still pass, failure is not expected, // they are just not thorough with respect to threading. BOOST_WARN_PREDICATE(std::not_equal_to<int>(), (global_count)( inner_loop * number_of_threads) ); } </snip>