[SDL] Atomic int/ptr operations?

Thu Jun 18 07:24:32 PDT 2009

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 <bob at pendleton.com> wrote:

>
>
> On Fri, Jun 12, 2009 at 3:46 AM, Sam Lantinga <slouken at libsdl.org> 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<http://msdn.microsoft.com/en-us/library/ms686353%28VS.85%29.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 <bob at pendleton.com> 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 at pendleton.com>
>>> 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
>>> >
>>>
>>>
>>>
>>> --
>>> +-----------------------------------------------------------
>>> + Bob Pendleton: writer and programmer
>>> + email: Bob at Pendleton.com
>>> + web: www.TheGrumpyProgrammer.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
>>
>>
>
>
> --
> +-----------------------------------------------------------
> + Bob Pendleton: writer and programmer
> + email: Bob at Pendleton.com
> + web: www.TheGrumpyProgrammer.com
>
>

-- 
+-----------------------------------------------------------
+ Bob Pendleton: writer and programmer
+ email: Bob at Pendleton.com
+ web: www.TheGrumpyProgrammer.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20090618/b858a67c/attachment.htm>