Re: [boost] shared_ptr under OS X

From: Matt Hurd (matt.hurd_at_[hidden])
Date: 2005-08-23 04:13:20

> On 23/08/05, Ben Artin <macdev_at_[hidden]> wrote:
> In article <045D1135-E8F5-4BF3-82BE-813C835E31FC_at_[hidden]>,
>  Steve Ramsey <steve_at_[hidden]> 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>