Re: GAtomic ABI and win32 implementation

[Hans Breuer <Hans Breuer org>]

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 ?

Thanks,
        Hans

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