Re: Atomic increment/decrement

[Andy H. <an...@jt...>]

Deborah Goldsmith wrote:
> 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 [...]
> 
> 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).

It's true that u_setAtomicIncDecFunctions() is set up to work only if 
ICU hasn't been initialized yet.  I was imagining that the Darwin 
implementation wouldn't use this function, but would slide in as 
conditional code in the base inc/dec, leaving 
u_setAtomicIncDecFunctions() available for user level code.   It's also 
true that mutex init is not a safe place to initialize the inc/dec 
function pointers - if an app omits calling u_init() there is no 
guarantee that atomic inc/dec wont be used before the first mutex usage.

The Darwin implementation could do a single null function pointer check 
on every call to atomic inc or dec, initializing the function pointers 
on the first call to atomic inc.  It wouldn't matter if ICU was already 
initialized - after the point where u_setAtomicIncDecFunctions() would work.


Regarding doing an inline-assembly implementation,

> 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.
> 
Oh well.  Never mind that suggestion.

I'm kind of curious as to what's been added to the PPC atomic 
instructions - I'll have to look it up.  Early PPCs, and presumably all 
since, had a load-and-reserve-memory and a conditional-store that, 
together, could be used to implement any atomic operations.  Maybe newer 
CPUs have something more efficient for atomic increments.  Or maybe the 
OS provides different implementations depending on whether the system 
has multiple CPUs.

-- 
    Andy Heninger
    hen...@us...