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.On Fri, Jun 12, 2009 at 3:46 AM, Sam Lantinga wrote:
See ya,
–Sam
On Tue, Jun 9, 2009 at 11:03 AM, Bob Pendleton <@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<@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
–
±----------------------------------------------------------
