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