Message-ID:
? ? ? ?<AANLkTin=4-kboB2Wtv+u5CHz0C4ycCEosEQ2s9p6_jhf at mail.gmail.com>
Content-Type: text/plain; charset=“iso-8859-1”
It may be useful to have this return the old value stored in the atomic.
One
could check if the swap has occurred by comparing the return value to
oldval.
However, in the case the swap fails, one can then inspect the value to
which
it’s been changed.
I don’t know if any platforms that LACK Compare-and-swap have it, but
I do know that some platforms have a Compare-and-store. Thus, the
current proposal for CAS might allow for optimization on more
platforms.
Additionally, some platforms use transactional operations for atomics
that fail if the address involved has been accessed between paired
transactional read and transactional write operations. Therefor, these
platforms can fail even if the value in the memory location is the
same now as it was when the operation began, which could lead to
situations where you don’t have a clue whether the CAS failed or
succeeded because the return value will be identical in either case. I
believe that the current form of the function would better represent
such things.
Interesting, I didn’t think about that. ?I did change the API to return the
old value, but maybe a bool is better to better avoid the ABA problem? ?I
don’t know that we can portably guarantee ABA avoidance though.
Suggestions?
It honestly isn’t likely to have much affect on me, because I mostly
compile for x86, but my personal advice is to switch back to the
SDL_bool return. If successful, then the caller already has all of the
info they need, and if it fails then it isn’t much work to do an
atomic read.
We should add a note to the documentation warning about how this
particular quirk can pop up on some architectures though, then warn
that it is ONLY a quirk and NOT a guarantee (if they want a guarantee
then they can write a transactional memory library)
On the note of documentation, I saw that you said you were going to
make a mailing list for developing documentation on, but I haven’t
seen a link on the SDL mailing list page. Am I looking in the wrong
place?> Date: Sat, 15 Jan 2011 14:16:25 -0800
From: Sam Lantinga
To: SDL Development List
Subject: Re: [SDL] Atomic API proposal
On Sat, Jan 15, 2011 at 1:33 PM, Jared Maddox <@Jared_Maddox>wrote:
I haven’t made the mailing list yet, it’s on my TODO list for Monday.On Sat, Jan 15, 2011 at 8:04 PM, Jared Maddox wrote:
Date: Sat, 15 Jan 2011 14:16:25 -0800
From: Sam Lantinga <@slouken>
To: SDL Development List
Subject: Re: [SDL] Atomic API proposal
Message-ID:
<AANLkTin=4-kboB2Wtv+u5CHz0C4ycCEosEQ2s9p6_jhf at mail.gmail.com<4-kboB2Wtv%2Bu5CHz0C4ycCEosEQ2s9p6_jhf at mail.gmail.com>
Content-Type: text/plain; charset=“iso-8859-1”
On Sat, Jan 15, 2011 at 1:33 PM, Jared Maddox <absinthdraco at gmail.com wrote:
It may be useful to have this return the old value stored in the
atomic.
One
could check if the swap has occurred by comparing the return value to
oldval.
However, in the case the swap fails, one can then inspect the value to
which
it’s been changed.
I don’t know if any platforms that LACK Compare-and-swap have it, but
I do know that some platforms have a Compare-and-store. Thus, the
current proposal for CAS might allow for optimization on more
platforms.
Additionally, some platforms use transactional operations for atomics
that fail if the address involved has been accessed between paired
transactional read and transactional write operations. Therefor, these
platforms can fail even if the value in the memory location is the
same now as it was when the operation began, which could lead to
situations where you don’t have a clue whether the CAS failed or
succeeded because the return value will be identical in either case. I
believe that the current form of the function would better represent
such things.
Interesting, I didn’t think about that. I did change the API to return
the
old value, but maybe a bool is better to better avoid the ABA problem? I
don’t know that we can portably guarantee ABA avoidance though.
Suggestions?
It honestly isn’t likely to have much affect on me, because I mostly
compile for x86, but my personal advice is to switch back to the
SDL_bool return. If successful, then the caller already has all of the
info they need, and if it fails then it isn’t much work to do an
atomic read.
We should add a note to the documentation warning about how this
particular quirk can pop up on some architectures though, then warn
that it is ONLY a quirk and NOT a guarantee (if they want a guarantee
then they can write a transactional memory library)
On the note of documentation, I saw that you said you were going to
make a mailing list for developing documentation on, but I haven’t
seen a link on the SDL mailing list page. Am I looking in the wrong
place?
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