Miro Jurisic wrote: [...]
In article <4254643E.E4AE9DAE@web.de>, Alexander Terekhov <terekhov@web.de> 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.