|
Boost : |
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk