[boost] Re: shared_ptr on ppc?

From: Miro Jurisic (macdev_at_[hidden])
Date: 2005-04-07 13:30:24

In article <4254EFCC.29894E10_at_[hidden]>, Alexander Terekhov <terekhov_at_[hidden]> 
wrote:

> Miro Jurisic wrote: [...]
> > 
> > In article <4254643E.E4AE9DAE_at_[hidden]>, Alexander Terekhov <terekhov_at_[hidden]> 
> > wrote:
> > 
> > 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.

I don't know if they do, but if you give me a specific question to ask, I'll ask 
it. I have enough contacts at Apple that I should be able to help.

> > 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.

This sounds like an attempt at premature optimization to me, frankly. Have you 
profiled Apple's atomic primitives to determine that they are going to be 
problematic, or are you just guessing? I would rather have code that runs 
slightly slower but doesn't need to be revised when new hardware comes out.

> > 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.

Sorry, I don't know what you are talking about. Not only do I not see such APIs 
on Mac OS, google also doesn't reveal such APIs anywhere else.

meeroh