[boost] Re: shared_ptr on ppc?

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2005-04-07 03:31:08

Miro Jurisic wrote:
[...]
> 
> In article <4254643E.E4AE9DAE_at_[hidden]>, Alexander Terekhov <terekhov_at_[hidden]>
> wrote:
> 
> > Miro Jurisic wrote:
> >
> > [... Apple's lwarc/stwcx smells-like-FUD stuff ...]
> >
> > I gather that it's all about "hard to grasp" msync stuff, nothing else.
> >
> > regards, alexander.
> 
> As I said elsewhere in the thread, I freely admit doubt because I do not have
> insight into all the CPU-specific issues here, but:
> 
> 1. Apple has an API that works
> 2. Apple has an API that doesn't depend on the compiler
> 3. Apple makes an implicit commitment to continue making this API work as new
> hardware is released

That's all fine and dandy, expect that AFAIK Apple has no refcounting 
API with optimal msync semantics for basic thread-safety at all. Yet.

> 
> Leaving aside the question of what the 1998 CompareAndSwap looked like (because
> that's not what it looks like today), as far as I can tell there is no technical
> reason to believe that the boost code would be better than Apple's, and there is
> a good reason that calling Apple's APIs would make our code easier to maintain
> both in terms of compiler support and in terms of new hardware support.

I suppose that Apple provides fully-fenced CAS mimicking original IBM's 
CAS on mainframes. That's suboptimal (even apart from msync) on Power.

> 
> Let's not succumb to NIH syndrome here. When a library that boost can depend on
> (OS, STL, ANSI C, etc) provides functionality that we need, as is the case here,
> we should use it.

We should use Apple's atomic_decrement_weak(), atomic_decrement_strong(), 
atomic_decrement_strong(), atomic_increment_naked(), and 
atomic_increment_naked_if_not_zero(). 

Drop me a link to Apple's man page for that stuff ASAP, please.

regards,
alexander.