Error on building SDL_spinlock.c with MinGW & Msys

SDL Development
1

I get the whole “need_spinlock_implementation” issue.

Anyway, MinGW supports the InterlockedCompareExchange intrinsic. I fixed the issue like so:
— #elif defined(_MSC_VER)
+++ #elif defined(_MSC_VER) || (defined(WIN32) && defined(GNUC))

Is it actually safe to not have a barrier on the unlock with your implementation? mfence exists on x86 and x64 CPUs supporting SSE2 to add this functionality, and IIRC a locked no-op should act similar.------------------------
EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

2

An atomic operation will act as a memory barrier on x86. Win32
InterlockedXxxx() APIs have 3 forms of atomic operations:

InterlockedXxxxAcquire - “acquire” memory semantics
InterlockedXxxxRelease - “release” memory semantics
InterlockedXxxx [no suffix] - acts as both “acquire” and "release"
semantics, i.e. full barrier.

So in effect, using InterlockedCompareExchange() is actually performing a
full memory barrier.

Also that “defined(WIN32)” should be “defined(_WIN32)” – additional
underscore added.On Wed, May 11, 2011 at 4:58 PM, Nathaniel J Fries wrote:

I get the whole “need_spinlock_implementation” issue.

Anyway, MinGW supports the InterlockedCompareExchange intrinsic. I fixed
the issue like so:
— #elif defined(_MSC_VER)
+++ #elif defined(_MSC_VER) || (defined(WIN32) && defined(GNUC))

Is it actually safe to not have a barrier on the unlock with your
implementation? mfence exists on x86 and x64 CPUs supporting SSE2 to add
this functionality, and IIRC a locked no-op should act similar.

EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

3

Patrick Baggett wrote:

An atomic operation will act as a memory barrier on x86. Win32 InterlockedXxxx() APIs have 3 forms of atomic operations:

InterlockedXxxxAcquire - “acquire” memory semantics?
InterlockedXxxxRelease - “release” memory semantics
InterlockedXxxx?[no suffix] - acts as both “acquire” and “release” semantics, i.e. full barrier.

So in effect, using InterlockedCompareExchange() is actually performing a full memory barrier.

Also that “defined(WIN32)” should be “defined(_WIN32)” – additional underscore added.

  I get the whole "__need_spinlock_implementation__" issue.

Anyway, MinGW supports the InterlockedCompareExchange intrinsic. I fixed the issue like so:
— #elif defined(_MSC_VER)
+++ #elif defined(_MSC_VER) || (defined(WIN32) && defined(GNUC))

Is it actually safe to not have a barrier on the unlock with your implementation? mfence exists on x86 and x64 CPUs supporting SSE2 to add this functionality, and IIRC a locked no-op should act similar.

EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/ (http://natefries.net/)

SDL mailing list
SDL at lists.libsdl.org (SDL at lists.libsdl.org)
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org (http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org)

MinGW defines WIN32, and so does cygwin-gcc IIRC. So it shouldn’t matter, since the MSVC test is prior to that.> On Wed, May 11, 2011 at 4:58 PM, Nathaniel J Fries <@Nathaniel_J_Fries (@Nathaniel_J_Fries)> wrote:

EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/