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.
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
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
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.
Back to lurking…On Wed, Oct 17, 2012 at 2:36 PM, Edward Rudd wrote:
SDL mailing list
SDL at lists.libsdl.org