Re: GAtomic ABI and win32 implementation

[Hans Breuer <Hans Breuer org>]

At 17:45 28.02.04, Sebastian Wilhelmi wrote:
> Moin Hans,
>
> > > >       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 ?
>
> Fixed in CVS. Thanks.
Still wondering (I' m probably too old for so much #ifdefs; and all these 
asm doesn't improve readability either ;-)

- Should the ABI really differ depending on the compile time switch,
  G_THREADS_ENABLED ?
- Don't we want the fallback implementations in any case ?

> > >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 ...
>
> I see. In that case however you might actually be better off just using
> the generic i486 functions. What's wrong with that? Using the
> InterLocked* Functions in gatomic.c will be slower because of two nested
> functions calls instead of an inline function. And the i486 version is
> correct, too. The only problem of course is, if you compile with
> non-gcc. I think, that's your motivation.....

Yepp, but also the ABI between the msvc and the mingw build should be 
compatible, so both need to export the same functions.


> In that case you could try the attached patch (untested..):
>
> > >You might have to add casting (no idea, I have no windows around).
> > >
Yeah, but this one appeared to be simple. I also added some check for 
pointer being 32-bit, cause there is no 
InterlockedExchangeCompareExchangePointer (but InterlockedCompareExchange() 
does take PVOID, I'm eager to see this fixed in win64 :)

Thanks,
        Hans

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