Hello, I just wanted to report an incoherence between the behavior of
SDL_mutexV in Windows and Linux. When one mutex is already unlocked, the call
to that function on that mutex should just return a 0 (success) and go on.
This is what the Linux implementation does, but Windows fails (returns -1).
Since we cannot force MS to fix it, SDL should somehow correct this buggy
behavior, or at least notice it in the documentation.
Cheers.–
Pablo Diaz-Gutierrez
Granada, Spain
Hello, I just wanted to report an incoherence between the behavior of
SDL_mutexV in Windows and Linux. When one mutex is already unlocked, the call
to that function on that mutex should just return a 0 (success) and go on.
This is what the Linux implementation does, but Windows fails (returns -1).
Since we cannot force MS to fix it, SDL should somehow correct this buggy
behavior, or at least notice it in the documentation.
Not that you aren’t correct, but as a rule of thumb if you are unlocking
a mutex more than you are locking it, you may be in trouble in your threaded
code design.
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
Yes. Unlock only what you lock, and you should be fine.
Either way, maybe it would be a good idea to point out in the docs that unlocking an unlocked mutex is an error, and that the behavior is undefined? (That way, no one can claim it’s a bug… 
//David
.---------------------------------------
| David Olofson
| Programmer
| david.olofson at reologica.se |
|---|
| Address: |
| REOLOGICA Instruments AB |
| Scheelev?gen 30 |
| 223 63 LUND |
| Sweden |
| --------------------------------------- |
| Phone: 046-12 77 60 |
| Fax: 046-12 50 57 |
| Mobil: |
| E-mail: david.olofson at reologica.se |
| WWW: http://www.reologica.se |
`-----> We Make Rheology RealOn Wed, 12/06/2002 20:50:44 , Sam Lantinga wrote:
Hello, I just wanted to report an incoherence between the behavior of
SDL_mutexV in Windows and Linux. When one mutex is already unlocked, the call
to that function on that mutex should just return a 0 (success) and go on.
This is what the Linux implementation does, but Windows fails (returns -1).
Since we cannot force MS to fix it, SDL should somehow correct this buggy
behavior, or at least notice it in the documentation.Not that you aren’t correct, but as a rule of thumb if you are unlocking
a mutex more than you are locking it, you may be in trouble in your threaded
code design.
Not that you aren’t correct, but as a rule of thumb if you are unlocking
a mutex more than you are locking it, you may be in trouble in your threaded
code design.Yes. Unlock only what you lock, and you should be fine.
Either way, maybe it would be a good idea to point out in the docs
that unlocking an unlocked mutex is an error, and that the behavior is
undefined? (That way, no one can claim it’s a bug…
Well, what should it be? Error or success to unlock an unlocked mutex?
I’ll make the code patch if someone makes the docs patch. 
–ryan.
Well, what should it be? Error or success to unlock an unlocked mutex?
From the pthreads man page:
On ``error checking'' mutexes, pthread_mutex_unlock actu?
ally checks at run-time that the mutex is locked on
entrance, and that it was locked by the same thread that
is now calling pthread_mutex_unlock. If these conditions
are not met, an error code is returned and the mutex
remains unchanged. ``Fast'' and ``recursive'' mutexes
perform no such checks, thus allowing a locked mutex to be
unlocked by a thread other than its owner. This is non-
portable behavior and must not be relied upon.
I’m inclined to say that it is an error to unlock a mutex that you
have not locked, and if you do so, the behavior is undefined. This
is because on some platforms it is either expensive or impossible
at the API level to know whether the mutex has been locked by your
code.
I have modified the SDL headers to mention this. Martin, can you
update the documentation?
Thanks!
-Sam Lantinga, Software Engineer, Blizzard Entertainment
If it’s undefined, it’s… well, undefined!
That said, it might make debugging easier if behavior is as concistent as possible accross platforms. (Not everyone can test on all platforms regularly.)
//David
.---------------------------------------
| David Olofson
| Programmer
| david.olofson at reologica.se |
|---|
| Address: |
| REOLOGICA Instruments AB |
| Scheelev?gen 30 |
| 223 63 LUND |
| Sweden |
| --------------------------------------- |
| Phone: 046-12 77 60 |
| Fax: 046-12 50 57 |
| Mobil: |
| E-mail: david.olofson at reologica.se |
| WWW: http://www.reologica.se |
`-----> We Make Rheology RealOn Thu, 13/06/2002 16:05:27 , Ryan C. Gordon wrote:
Not that you aren’t correct, but as a rule of thumb if you are unlocking
a mutex more than you are locking it, you may be in trouble in your threaded
code design.Yes. Unlock only what you lock, and you should be fine.
Either way, maybe it would be a good idea to point out in the docs
that unlocking an unlocked mutex is an error, and that the behavior is
undefined? (That way, no one can claim it’s a bug…Well, what should it be? Error or success to unlock an unlocked mutex?
Not that you aren’t correct, but as a rule of thumb if you are unlocking
a mutex more than you are locking it, you may be in trouble in your threaded
code design.Yes. Unlock only what you lock, and you should be fine.
Either way, maybe it would be a good idea to point out in the docs
that unlocking an unlocked mutex is an error, and that the behavior is
undefined? (That way, no one can claim it’s a bug…
Well, what should it be? Error or success to unlock an unlocked mutex?
Personally, I think it should be a success. When I get back from a
state changing call lilke that, all I care is that the state is what I
want it to be in order to proceed.
I'll make the code patch if someone makes the docs patch. :)
--ryan.On Thu, 2002-06-13 at 16:05, Ryan C. Gordon wrote:
_______________________________________________
SDL mailing list
SDL at libsdl.org
End of Rant.
Jimmy
Jimmy’s World
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: This is a digitally signed message part
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020618/267b275e/attachment.pgp
> Either way, maybe it would be a good idea to point out in the docs > that unlocking an unlocked mutex is an error, and that the behavior is > undefined? (That way, no one can claim it's a bug... ;-) Well, what should it be? Error or success to unlock an unlocked mutex?
Personally, I think it should be a success. When I get back from a
state changing call lilke that, all I care is that the state is what I
want it to be in order to proceed.
It’s simply not fast enough to be practical in a cross-platform way.
If you really need unlocking an unlocked mutex to be a success, then
you’ll need to wrap the mutexes with your own state management information
to find out what the current state of the mutex is. You’ll probably
need an additional real mutex or some sort of interlocked data calls
to prevent race conditions in your new code.
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment