SDL MutexTryLock API Addition

SDL Development
1

While working on my next set of Mac/Linux game ports I noticed an omission in the SDL2 Mutex API , the TryLock. The Semaphore’s have a TryWait, but no TryLock on the Mutex… So I implemented it and have included it in a patch on bug #1623

http://bugzilla.libsdl.org/show_bug.cgi?id=1623

On a related topic, should we also look into renaming the Mutex lock/unlock methods to match the consistency of other methods?

For example, the Semaphore API has CreateSemaphore , SemWait, SemPost, SemTryWait, where as the Mutex API has CreateMutex, mutexP, mutexV (with aliases of LockMutex and UnlockMutex). (where did V and P even come from honestly? I’ve always been curious)

It seems a more consistent naming would be

SDL_CreateMutex
SDL_DestroyMutex
SDL_MutexLock
SDL_MutexTryLock
SDL_MutexUnlock

Thoughts anyone?

Edward Rudd
OutOfOrder.cc
Skype: outoforder_cc
317-674-3296

2

While working on my next set of Mac/Linux game ports I noticed an omission in the SDL2 Mutex API , the TryLock. The Semaphore’s have a TryWait, but no TryLock on the Mutex… So I implemented it and have included it in a patch on bug #1623

It is not missing, it is not there because it does not do what people
expect it to do. Invariably people use a TryMutex to busy wait on a
mutex and then complain that when they lock the mutex they wind up
waiting any way, or that they never see the mutex in a free state.
Mutexes do not work quite the way people expect them to work. My
experience is that it takes a lot of work with real multiprocessors
and lots of multithreaded code to get to where you understand why
trywait on mutexes is pretty much a waste of space. IMHO it is in most
APIs because they were written way back in the dawn times (which I
personally remember, I was alive and coding back then) and the people
who designed those APIs hadn’t had time to realize just how worthless
TryWait on a mutex is. But, that is just my opinion.

The thing is that people expect mutexes to act like atomic operations,
but they don’t. Mutexes are often implemented as system calls and can
have all sorts of unexpected side effects on your process scheduling.
If you want a busy wait that works pretty much the way you expect it
to work, then use the atomic operations. They have a TryLock. They
work pretty much the way you expect them to work. They are nice and
efficient in both CPU and memory usage. Not to mention that I spent
many years lobbying and writing and lobbying and coding and … to get
them into SDL so it makes me very very happy when they get used.
Please, just take a look at the atomic ops and don’t worry about
adding TryWait to mutexes.

http://bugzilla.libsdl.org/show_bug.cgi?id=1623

On a related topic, should we also look into renaming the Mutex lock/unlock methods to match the consistency of other methods?

For example, the Semaphore API has CreateSemaphore , SemWait, SemPost, SemTryWait, where as the Mutex API has CreateMutex, mutexP, mutexV (with aliases of LockMutex and UnlockMutex). (where did V and P even come from honestly? I’ve always been curious)

It seems a more consistent naming would be

SDL_CreateMutex
SDL_DestroyMutex
SDL_MutexLock
SDL_MutexTryLock
SDL_MutexUnlock

Thoughts anyone?

Yeah, it would be much more consistent. It would also break every bit
of code that uses the existing names. Every bit of old code would have
to be modified. Libraries I wrote 8 years ago that I have not had to
modify in 8 years that are used by a whole bunch of programs would
suddenly have to be modified. Kind of a pain in the ass don’t you
think? OTOH, deprecation and #define are great things too. So, it
could be done without a lot of problems. But, it doesn’t seem like it
is much of of a bother. Changing all that code would be a bother.

Personally, I’d make everything have the noun followed by the verb so
they would all be MutexCreate, SemCreate, MutexDestroy, SemDestroy,…
But, so what.

To answer your last question, P and V are from Edsger W. Dijkstra
(http://en.wikipedia.org/wiki/Edsger_Dijkstra) the man who invented
the counting semaphore. According to wikipedia
(http://en.wikipedia.org/wiki/Semaphore_(programming)):

The canonical names P and V come from the initials of Dutch words. V
stands for verhogen (“increase”). Dijkstra wrote that he intended P
to stand for the portmanteau prolaag, short for probeer te verlagen,
literally “try to reduce,” or to parallel the terms used in the other
case, “try to decrease.” This confusion stems from the fact that the
words for increase and decrease both begin with the letter V in Dutch,
and the words spelled out in full would be impossibly confusing for
those not familiar with the Dutch language.

So it is a case of he who invented it named it. And, he didn’t invent
a Try operation, it wouldn’t make any sense. If you do not know who
Dijkstra was or what he did you might want to stop coding for a while
and go read some of his books. His stuff on cooperating sequential
processes is wonderful. It is the only way I know of to organize
parallel code that actually works. But, nobody seems to teach it, and
nobody seems to use it. And, people are always amazed when they see it
working. So sad.

Bob Pendleton

Back to lurking…On Wed, Oct 17, 2012 at 2:36 PM, Edward Rudd wrote:

Edward Rudd
OutOfOrder.cc
Skype: outoforder_cc
317-674-3296

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

–
±----------------------------------------------------------

3

[snip]

The thing is that people expect mutexes to act like atomic operations,
but they don’t. Mutexes are often implemented as system calls and can
have all sorts of unexpected side effects on your process scheduling.
If you want a busy wait that works pretty much the way you expect it
to work, then use the atomic operations. They have a TryLock. They
work pretty much the way you expect them to work. They are nice and
efficient in both CPU and memory usage. Not to mention that I spent
many years lobbying and writing and lobbying and coding and … to get
them into SDL so it makes me very very happy when they get used.
Please, just take a look at the atomic ops and don’t worry about
adding TryWait to mutexes.

Thanks very much for this explanation. And I’ve seen very few of the game I’ve ported using the TryWait mechanism… , Though most of the time I just use straight up pthread to implement these things, but decided to use SDL2 this time around. So I may just fallback to using direct pthread, as I don’t know all the use-cases they use their wrapper class in the code to reliably choose to use the Atomic Locks… Their win32 implementation is the win32 CriticalSection API. In the end I don’t want to maintain a fork of SDL2 for this developers games, and I doubt they would want to either… So anything that I can get accepted upstream will make me happier :slight_smile: (so long as it is REASONABLE to include that is…)

And I was happy to see the Atomic ops in SDL2, as this engine code is full of those as well.

http://bugzilla.libsdl.org/show_bug.cgi?id=1623

On a related topic, should we also look into renaming the Mutex lock/unlock methods to match the consistency of other methods?

For example, the Semaphore API has CreateSemaphore , SemWait, SemPost, SemTryWait, where as the Mutex API has CreateMutex, mutexP, mutexV (with aliases of LockMutex and UnlockMutex). (where did V and P even come from honestly? I’ve always been curious)

It seems a more consistent naming would be

SDL_CreateMutex
SDL_DestroyMutex
SDL_MutexLock
SDL_MutexTryLock
SDL_MutexUnlock

Thoughts anyone?

Yeah, it would be much more consistent. It would also break every bit
of code that uses the existing names. Every bit of old code would have
to be modified. Libraries I wrote 8 years ago that I have not had to
modify in 8 years that are used by a whole bunch of programs would
suddenly have to be modified. Kind of a pain in the ass don’t you
think? OTOH, deprecation and #define are great things too. So, it
could be done without a lot of problems. But, it doesn’t seem like it
is much of of a bother. Changing all that code would be a bother.

Which is why I would ONLY suggest renaming them for SDL2, where things already have been “renamed” and is not currently at a released status.

Personally, I’d make everything have the noun followed by the verb so
they would all be MutexCreate, SemCreate, MutexDestroy, SemDestroy,…
But, so what.

Yeah, I would agree with that as well… It makes more sense to me and “groups” all the functions nicely when using auto-complete in an IDE :smiley:

Oh, and thanks for the historic explanation on the P/V naming.

Edward Rudd
OutOfOrder.cc
Skype: outoforder_cc
317-674-3296On Oct 17, 2012, at 17:24 , Bob Pendleton wrote:

On Wed, Oct 17, 2012 at 2:36 PM, Edward Rudd <@Edward_Rudd> wrote:

4

Yeah, it would be much more consistent. It would also break every bit
of code that uses the existing names. Every bit of old code would have
to be modified. Libraries I wrote 8 years ago that I have not had to
modify in 8 years that are used by a whole bunch of programs would
suddenly have to be modified. Kind of a pain in the ass don’t you

SDL_CreateThread() changed in SDL2, so those libraries need a tweak
already anyhow, so we might as well change other things while the
API/ABI is still evolving.

–ryan.

5

Yeah, it would be much more consistent. It would also break every bit
of code that uses the existing names. Every bit of old code would have
to be modified. Libraries I wrote 8 years ago that I have not had to
modify in 8 years that are used by a whole bunch of programs would
suddenly have to be modified. Kind of a pain in the ass don’t you

SDL_CreateThread() changed in SDL2, so those libraries need a tweak already
anyhow, so we might as well change other things while the API/ABI is still
evolving.

–ryan.

Go for it Ryan. Consistency in naming is a VERY good thing. And, as
Edward pointed out, when the names are presented in a sorted list by a
things like IDEs a consistent naming structure like Lib_NounVerb i.e
SDL_ThreadCreate or SDL_MutexDestroy will result in all the thread
functions being grouped together and all the Mutex functions beting
grouped together. Otherwise, If you use Lib_VerbNoun i.e.
SDL_CreateThread you get all the create function grouped together. It
might sound better in English, but that is actually a bug in English.

Bob PendletonOn Wed, Oct 17, 2012 at 7:45 PM, Ryan C. Gordon wrote:

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

–
±----------------------------------------------------------

6

Go for it Ryan. Consistency in naming is a VERY good thing. And, as
Edward pointed out, when the names are presented in a sorted list by a
things like IDEs a consistent naming structure like Lib_NounVerb i.e

Whoa, I was talking about changing the mutexV thing to LockMutex. Would
changing this to be Noun->Verb touch every entry point? That’s a bit too
salty for me.

–ryan.

7

Go for it Ryan. Consistency in naming is a VERY good thing. And, as
Edward pointed out, when the names are presented in a sorted list by a
things like IDEs a consistent naming structure like Lib_NounVerb i.e

Whoa, I was talking about changing the mutexV thing to LockMutex. Would
changing this to be Noun->Verb touch every entry point? That’s a bit too
salty for me.

oh, slight miscommunication…

There is an existing API naming scheme in SDL2, I think the goal
should be to make sure that it is used consistently. You should
absolutely NOT go through and change the names of the majority of the
entry points to fit some new naming scheme just because I, or anyone
else, say that it would be a good idea. There would have to be a
really really good reason. A reason good enough to convince you and
Sam and a whole lot of other people who would have to do a lot of work
to implement the changes and change a mountain of code. As you say,
way to salty for me.

Bob PendletonOn Thu, Oct 18, 2012 at 2:10 PM, Ryan C. Gordon wrote:

–ryan.

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

–
±----------------------------------------------------------

8

Whoa, I was talking about changing the mutexV thing to LockMutex.
Would changing this to be Noun->Verb touch every entry point?
That’s a bit too salty for me.

That is what this pirate is for :

http://www.syntheticsw.com/~wizard/tmp/salty_sam.jpg

Little historic joke, could not resist :slight_smile:

9

From SDL_mutex.h in SDL 2.0:

#define SDL_LockMutex(m) SDL_mutexP(m)
#define SDL_UnlockMutex(m) SDL_mutexV(m)On Thu, Oct 18, 2012 at 12:10 PM, Ryan C. Gordon wrote:

Go for it Ryan. Consistency in naming is a VERY good thing. And, as

Edward pointed out, when the names are presented in a sorted list by a
things like IDEs a consistent naming structure like Lib_NounVerb i.e

Whoa, I was talking about changing the mutexV thing to LockMutex. Would
changing this to be Noun->Verb touch every entry point? That’s a bit too
salty for me.

–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

10

Yes, but I was wondering if keeping the “mutexP” version was worth
anything. I assume everyone uses LockMutex, because “mutexP” is
basically unmaintainable (did you get them backwards? How would you know?).

–ryan.On 10/18/2012 11:55 PM, Sam Lantinga wrote:

From SDL_mutex.h in SDL 2.0:

#define SDL_LockMutex(m) SDL_mutexP(m)
#define SDL_UnlockMutex(m) SDL_mutexV(m)

11

From SDL_mutex.h in SDL 2.0:

#define SDL_LockMutex(m) SDL_mutexP(m)
#define SDL_UnlockMutex(m) SDL_mutexV(m)

Yes, but I was wondering if keeping the “mutexP” version was worth anything.
I assume everyone uses LockMutex, because “mutexP” is basically
unmaintainable (did you get them backwards? How would you know?).

Well, if you are Dutch… P() and V() might make sense to you.

Of course… if these are really the equivalent of P and V then the
correct names should be something like SDL_SemaphoreIncrement() and
SDL_SemaphoreDecrement() :slight_smile: (No that is not a suggestion! That is a
joke!)

Completely off topic, and if you want to talk about please take it up
with me privately or take it my list, but it seems that in the world
as it is today you pretty much have to learn English before you can
learn to program. And, I can tell you from personal experience that
working on code with comments in a foreign language is worse than code
with no comments at all.

Bob PendletonOn Thu, Oct 18, 2012 at 11:14 PM, Ryan C. Gordon wrote:

On 10/18/2012 11:55 PM, Sam Lantinga wrote:

–ryan.

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

–
±----------------------------------------------------------

12

Yes, since SDL2 is not meant to be API compatible, I’d support the
removal of the #define and having SDL_LockMutex directly, makes
binding for other languages a little easier. Also I would not mind
having the SDL_NounVerb structure that Bob proposed, it makes the API
a lot tider but it’s a lot of boring renaming work.
Anyone up for a patch? :slight_smile:
VittorioOn Fri, Oct 19, 2012 at 6:14 AM, Ryan C. Gordon wrote:

On 10/18/2012 11:55 PM, Sam Lantinga wrote:

From SDL_mutex.h in SDL 2.0:

#define SDL_LockMutex(m) SDL_mutexP(m)
#define SDL_UnlockMutex(m) SDL_mutexV(m)

Yes, but I was wondering if keeping the “mutexP” version was worth anything.
I assume everyone uses LockMutex, because “mutexP” is basically
unmaintainable (did you get them backwards? How would you know?).

–ryan.

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

13

Where are regular expressions which work with English grammar when you need
them?

Jonny DOn Tue, Oct 23, 2012 at 8:28 AM, Vittorio Giovara <vitto.giova at yahoo.it>wrote:

Yes, since SDL2 is not meant to be API compatible, I’d support the
removal of the #define and having SDL_LockMutex directly, makes
binding for other languages a little easier. Also I would not mind
having the SDL_NounVerb structure that Bob proposed, it makes the API
a lot tider but it’s a lot of boring renaming work.
Anyone up for a patch? :slight_smile:
Vittorio

On Fri, Oct 19, 2012 at 6:14 AM, Ryan C. Gordon wrote:

On 10/18/2012 11:55 PM, Sam Lantinga wrote:

From SDL_mutex.h in SDL 2.0:

#define SDL_LockMutex(m) SDL_mutexP(m)
#define SDL_UnlockMutex(m) SDL_mutexV(m)

Yes, but I was wondering if keeping the “mutexP” version was worth
anything.
I assume everyone uses LockMutex, because “mutexP” is basically
unmaintainable (did you get them backwards? How would you know?).

–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