Wouldn’t it be safer / easier to do this in a separate library? SDL_Atomic or something? So as to not break the main build.
Pat________________________________
From: bob@pendleton.com (Bob Pendleton)
To: A list for developers using the SDL library. (includes SDL-announce)
Sent: Friday, June 19, 2009 12:39:20 PM
Subject: Re: [SDL] Atomic int/ptr operations?
On Thu, Jun 18, 2009 at 10:35 PM, Sam Lantinga wrote:
Yeah, this all seems reasonable. Patch away! 
OK… you asked for it
Seriously, I can build a new .h and add a .c file with function definitions. I’ll even redo the test program. I’ll sketch out the Windows and Mac code, but, I will not be able to compile the Mac code, and maybe not the Windows code. So, I’ll check in the GCC code and circulate the rest on the list for other people to compile and test. When I have that code nailed down, I’ll check it in.
Bob Pendleton
On Thu, Jun 18, 2009 at 7:24 AM, Bob Pendleton wrote:
Here is info for MacOS. Interesting that they only support (AFAICT) 32 bit and 64 bit operands. That means, that if we want to work across platforms we can’t support 8 and 16 bit operands.
Mac OS X: http://developer.apple.com/documentation/Cocoa/Conceptual/Multithreading/ThreadSafety/ThreadSafety.html#//apple_ref/doc/uid/10000057i-CH8-SW14
I’m starting to think that these operations should be implemented as out of line functions in SDL. Doing it that way avoids problems with forced inclusion of os specific header files in user code and it appears to get rid of memory barrier problems (I said appears…). All at the cost of a very small reduction in performance.
Opinions? Flames? what do y’all think about this?
Bob Pendleton
On Wed, Jun 17, 2009 at 7:50 PM, Bob Pendleton wrote:
On Fri, Jun 12, 2009 at 3:46 AM, Sam Lantinga wrote:
Bob, this broke building on Windows. There are a couple problems.
First, including windows.h indirectly in SDL.h breaks SDL_sysvideo.h, which can be fixed, and potentially breaks application code that doesn’t compile with windows.h included.
Second, at least on Visual C++ there are warnings about using the wrong parameter types with the interlocked functions. These are correct, and even though some care has been taken to make sure the parameters are the same size, it makes me nervous.
Spent most of this afternoon reading the MSDN and GCC sections on atomic operations. No, not even close to reading all the stuff on MSDN. GCC docs were much more concise.
One with the code we now have is that it is intended to be inlined whenever possible. This makes good sense for performance, not such good sense for portability. That is where we get the problem with #including “windows.h” in a header file. That is pretty much a no no. Another problem is that the Windows functions are very picky about their argument sizes. As a fan of strong typing I can hardly complain about that. Yet another problem is all that assembly code. It made me nervous from the get go. AFAICT it isn’t needed on any platfrom supported by Windows or by GCC.
GCC: http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html
MSDN: http://msdn.microsoft.com/en-us/library/ms686353(VS.85).aspx
I think we need to go back to basics on this part of 1.3.
It looks like the size is going to have to be part of the function names, so if we want to support atomic ops on 8,16,32, and 64 bit fields we’re going to have 4 versions of each function.
We need to look at inlining. Looks to me like we can maybe get away with #define-ing the functions to map to the equivalent fuctions for each platform. This does assume that things like windows.h will get included “somewhere” before the #define-ed code is used. This may not be possible and the functions may have to be defined completely outside of the header files. I need input on this topic. The easiest way to implement this is out of line, but that does cost some performance.
It looks like there is no one atomic operation you can count on having on every processor type. At the least you get either an atomic test-and-set used to acquire a lock along with an atomic store used to release a lock or an atomic exchange that can be used to implement the test-and-set/relelase operations. After that you get into the whole set of fetch-and-op/op-and-fetch operations where op is a subset of (increment, add, decrement, subtract, and, xor, nand…).
Given either exchange or test-and-set/release you can implement all the others with a small loss of performance.
It looks to me like a reasonable set would be 8,16,32, and 64 bit operand versions of:
test-and-set/release
exchange
fetch-and-increment
fetch-and-add
fetch-and-decrement
fetch-and-subtract
increment-and-fetch
add-and-fetch
decrement-and-fetch
subtract-and-fetch
The difference between fetch-and-add and add-and-fetch is like the difference between i++ and ++i.
test-and-set returns SDL_bool,
release returns void
all the rest return one of Uint8, Uint16, Uint32, Uint64
hmm, should probably add busy-wait that works with exchange or test-and-set.
Double hmm, don’t worry, the final names will not have “-” in them, they’ll be SDL_TestAndSet() or something like that.
Ok, that’s my take on it, let me know what’s wrong with it.
See ya,
–Sam
On Tue, Jun 9, 2009 at 11:03 AM, Bob Pendleton wrote:
Ok, I applied the patch. Got everything to compile. Got it all to
install correctly. And ran testatomic. It all works on my Linux box so
I checked it in. No guarantees about any other platform. So, update
from svn and test it on everything. If you find a problem post patches
and we’ll get them in.
On Tue, Jun 9, 2009 at 11:16 AM, Donny Viszneki<donny.viszneki at gmail.com> wrote:
On Tue, Jun 9, 2009 at 9:04 AM, Bob Pendleton wrote:
On Tue, Jun 9, 2009 at 1:21 AM, Donny Viszneki<donny.viszneki at gmail.com> wrote:
xchg xchg xchg xchg xchg xchg xchg xchg …
so what platforms will that patch operate on?
Don’t know yet! What platforms are you interested in? Why don’t you
take a look too.
I did take a look! That’s what “xchg xchg xchg xchg” was all about!
Ya’know… I had not clue what that was about…
Bob Pendleton
–
http://codebad.com/
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
±----------------------------------------------------------
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
±----------------------------------------------------------
–
±----------------------------------------------------------
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
±----------------------------------------------------------