SDL blog post (double-checked locking)

Enjoy!

This is good information about memory barriers, but…out of curiosity,
why don’t we just allocate the slot during SDL_Init(), so we don’t have
any risk of race conditions and thus need no locks at all (under the
presumption that everything is off-limits from any thread before
SDL_Init, or can be special-cased, if say, the Message Box code needs TLS)?

(and we might as well always take the slot at startup, since we’ll
probably use it for SDL_SetError() sooner or later, meaning we’ll always
need it.)

–ryan.On 07/27/2013 01:28 PM, Sam Lantinga wrote:

http://slouken.blogspot.com/2013/07/lock-free-part-deux.html

Mostly because that code was also used by the error subsystem and I didn’t
want to make any assumptions about what had been called before an
SDL_SetError(). Also it was interesting to learn about. :)On Sat, Jul 27, 2013 at 8:58 PM, Ryan C. Gordon wrote:

On 07/27/2013 01:28 PM, Sam Lantinga wrote:

http://slouken.blogspot.com/**2013/07/lock-free-part-deux.**htmlhttp://slouken.blogspot.com/2013/07/lock-free-part-deux.html

This is good information about memory barriers, but…out of curiosity,
why don’t we just allocate the slot during SDL_Init(), so we don’t have any
risk of race conditions and thus need no locks at all (under the
presumption that everything is off-limits from any thread before
SDL_Init, or can be special-cased, if say, the Message Box code needs TLS)?

(and we might as well always take the slot at startup, since we’ll
probably use it for SDL_SetError() sooner or later, meaning we’ll always
need it.)

–ryan.

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

So is that GL context caching bugfix already in the trunk? Or in a
released version? And when is it going to hit the Steam Linux Runtime?

Leszek

2013/7/28 Sam Lantinga :> Mostly because that code was also used by the error subsystem and I didn’t

want to make any assumptions about what had been called before an
SDL_SetError(). Also it was interesting to learn about. :slight_smile:

On Sat, Jul 27, 2013 at 8:58 PM, Ryan C. Gordon wrote:

On 07/27/2013 01:28 PM, Sam Lantinga wrote:

http://slouken.blogspot.com/2013/07/lock-free-part-deux.html

This is good information about memory barriers, but…out of curiosity,
why don’t we just allocate the slot during SDL_Init(), so we don’t have any
risk of race conditions and thus need no locks at all (under the presumption
that everything is off-limits from any thread before SDL_Init, or can be
special-cased, if say, the Message Box code needs TLS)?

(and we might as well always take the slot at startup, since we’ll
probably use it for SDL_SetError() sooner or later, meaning we’ll always
need it.)

–ryan.


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

Good questions all. It is in trunk, and in the current release candidate.
It will hit the Steam Linux Runtime as soon as it’s released.On Sun, Jul 28, 2013 at 12:28 AM, Leszek Godlewski wrote:

So is that GL context caching bugfix already in the trunk? Or in a
released version? And when is it going to hit the Steam Linux Runtime?

Leszek

2013/7/28 Sam Lantinga <@slouken>:

Mostly because that code was also used by the error subsystem and I
didn’t
want to make any assumptions about what had been called before an
SDL_SetError(). Also it was interesting to learn about. :slight_smile:

On Sat, Jul 27, 2013 at 8:58 PM, Ryan C. Gordon wrote:

On 07/27/2013 01:28 PM, Sam Lantinga wrote:

http://slouken.blogspot.com/2013/07/lock-free-part-deux.html

This is good information about memory barriers, but…out of curiosity,
why don’t we just allocate the slot during SDL_Init(), so we don’t have
any

risk of race conditions and thus need no locks at all (under the
presumption

that everything is off-limits from any thread before SDL_Init, or can
be

special-cased, if say, the Message Box code needs TLS)?

(and we might as well always take the slot at startup, since we’ll
probably use it for SDL_SetError() sooner or later, meaning we’ll always
need it.)

–ryan.


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

Great, thanks! I stumbled upon that bug a few weeks ago, been working
around it by making the main context current. Glad to hear the hack can be
soon removed.

Leszek
28-07-2013 19:49, “Sam Lantinga” napisa?(a):> Good questions all. It is in trunk, and in the current release candidate.

It will hit the Steam Linux Runtime as soon as it’s released.

On Sun, Jul 28, 2013 at 12:28 AM, Leszek Godlewski <@Leszek_Godlewski>wrote:

So is that GL context caching bugfix already in the trunk? Or in a
released version? And when is it going to hit the Steam Linux Runtime?

Leszek

2013/7/28 Sam Lantinga :

Mostly because that code was also used by the error subsystem and I
didn’t
want to make any assumptions about what had been called before an
SDL_SetError(). Also it was interesting to learn about. :slight_smile:

On Sat, Jul 27, 2013 at 8:58 PM, Ryan C. Gordon wrote:

On 07/27/2013 01:28 PM, Sam Lantinga wrote:

http://slouken.blogspot.com/2013/07/lock-free-part-deux.html

This is good information about memory barriers, but…out of curiosity,
why don’t we just allocate the slot during SDL_Init(), so we don’t
have any

risk of race conditions and thus need no locks at all (under the
presumption

that everything is off-limits from any thread before SDL_Init, or
can be

special-cased, if say, the Message Box code needs TLS)?

(and we might as well always take the slot at startup, since we’ll
probably use it for SDL_SetError() sooner or later, meaning we’ll
always

need it.)

–ryan.


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

Interesting read, thanks. Would you elaborate on how you arrived at the
decision to implement your own TLS in SDL instead of using the various built-in
platform mechanisms (such as GCC __thread, Windows __declspec(thread), Cocoa
threadDictionary, pthread getspecific, etc.)?

-JohnOn 07/27/2013 01:28 PM, Sam Lantinga wrote:

http://slouken.blogspot.com/2013/07/lock-free-part-deux.html

Enjoy!


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

Mostly because I wanted to guarantee that it would be available and have
the same behavior across all platforms.

If you wanted to implement a thread-local variable in application code
using the mechanisms you listed, you would need vastly different
implementations for different compilers, platforms, etc.On Sun, Jul 28, 2013 at 11:14 AM, John wrote:

Interesting read, thanks. Would you elaborate on how you arrived at the
decision to implement your own TLS in SDL instead of using the various
built-in platform mechanisms (such as GCC __thread, Windows
__declspec(thread), Cocoa threadDictionary, pthread getspecific, etc.)?

-John

On 07/27/2013 01:28 PM, Sam Lantinga wrote:

http://slouken.blogspot.com/**2013/07/lock-free-part-deux.**htmlhttp://slouken.blogspot.com/2013/07/lock-free-part-deux.html

Enjoy!

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

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