MemoryBarrier and MinGW

[Earnie Boyd]

I know your comment states "this is what GLib does, hopefully it's
right..." at line 3085 but when I looked at GLib they do not always use
the function.  If fact it should only be used in the very specific
architecture.  GLib has the following #if logic.

#elif defined (G_PLATFORM_WIN32) &&
defined(HAVE_WIN32_BUILTINS_FOR_ATOMIC_OPERATIONS)

I'm guessing the HAVE_WIN32_BUILTINS_FOR_ATOMIC_OPERATIONS is the big
thing here.  It is left undefined in config.h.  Reviewing the rest of
gatomic.c from GLib I see the path it takes for MinGW is to use its own
set of routines to perform the locks or in other words the #else path
of the above condition.

Looking into the MSDN documentation for MemoryBarrier brings me to the
sad conclusion that it is really part of the .NET services and not
really part of Win32 API.  However the Interlocked services is part of
the API and should be used while MemoryBarrier should be conditioned.

http://msdn.microsoft.com/en-us/library/ms684122(v=vs.85).aspx

These are defined in Winbase.h in MinGW.

Earnie