Re: Atomic increment/decrement

On Nov 18, 2004, at 11:13 AM, Andy Heninger wrote:
> If Darwin has a dll/loader function to look up the address of a 
> library entry point given its name (it probably does), you could use 
> that at ICU mutex initialization time to find the atomic 
> increment/decrement functions if they exist.  This would sidestep the 
> undefined symbol problem at build time.

I'm looking into this. Darwin uses dyld, which does have functions for 
dynamic loading. One issue is that it's not clear to me that there *is* 
a "mutex init time": mutex's get init'd when they're used. I notice 
that functions like u_setAtomicIncDecFunctions refuse to change the 
functions if cmemory_inUse() returns true. I'd hate to have to test 
this on every entry to umtx_atomic_inc or umtx_atomic_dec (it would 
require at least a boolean, gDarwinAtomicChecked, in addition to the 
test as to whether there are client-supplied overrides).
>
> Another possibility is to just implement the functions yourself. 
> PowerPC CPUs have had the necessary instructions since the beginning 
> of time, the required assembly language can no doubt be cribbed from 
> somewhere, and with only one compiler and processor family to worry 
> about, a little inline assembly code may actually be simpler than 
> dealing with operating system version dependencies.

Actually, these functions are part of a small set that are implemented 
via something in Darwin called the "comm page"; the functions that live 
there can have CPU-model-dependent implementations (e.g. one for 
G3/750, one for G4/7447A, one for G4/7457, and so on). So copying them 
inline won't work (or I'd have to worry about CPU model errata, etc.).

Also, while Mac OS X runs only on PowerPC family processors, Darwin 
runs on both PowerPC and Intel. ICU is integrated at the Darwin level 
and it's a hard requirement that it work on Intel in Darwin.

Deborah