Re: Atomic increment/decrement
Andy Heninger <[email protected]> Mon, 22 Nov 2004 10:10:03 -0800
| Newsgroups | gmane.comp.lib.icu.general |
|---|---|
| Message-ID | <[email protected]> |
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
[email protected]