Re: GAtomic ABI and win32 implementation

At 16:35 28.02.04, Sebastian Wilhelmi wrote:
Moin Hans,

> The current win32 build does export the following
> g_atomic_ funtion, which may or may not be intended
> to be part of the ABI (which should not change after
> freezing the API and probaly is an issue on ELF platforms
> as well) :
>       g_atomic_int_compare_and_exchange_fallback
>       g_atomic_int_exchange_and_add_fallback
>       g_atomic_int_get_fallback
>       g_atomic_pointer_compare_and_exchange_fallback
>       g_atomic_pointer_get_fallback

They have to be exported in general, as we need them for e.g. non-gcc
compilers, which can't do the inline assembler stuff.
Two of them were not exportable due to missing implementation, i.e.
;       g_atomic_int_get_fallback
;       g_atomic_pointer_get_fallback
seem to be missing with my current configuration. Do you have tested the none- GCC case so that this is just a win32 issue, I'm looking for ?

ON win32 however
they are not needed, if you use the InterLocked* functions.

I'd rather like to implement all of them on win32 with the Interlocked*
family of functions, rather than putting any win32 api into glib headers.

At least The GIMP and Dia are compiled on win32 with forced include
of msvc_recommended_pragmas.h , especially in this case :
#pragma warning(error:4013) /* 'function' undefined; assuming extern returning int */
which would break the build if noone includes <windows.h> before <glib.h>.

OTOH including windows.h would not only break due to namespace clashes but also weaken the cross platform API glib provides ...

> ALso I would like to map g_atomic_*() to the native win32
> functions InterLockedCompareExchange() and
> InterlockedExchangeAdd().
> Some clarification how this should be done before freezing
> the API would be nice ;-)

I would start with the attached patch.

Question: Is G_ATOMIC_MEMORY_BARRIER really not needed for all win32
platforms? (ia64 comes to mind, or is ia64 not win32).

AFAIK ia64 would also mean win64, or it has to be compatible in pointer sizes with win32. [I haven't played with the win64 SDK yet and even don't know if there already is any win64 public available, but I guess not.]

You might have to add casting (no idea, I have no windows around).

Please run tests/atomic-test to test, whether it works.
Will do, but running such tests without actually having a dual processor machine wont show any but the most simple errors. Wouldn't it be feasible to at least extend the test to use multiple threads ?


-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to
get along without it.                -- Dilbert

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]