Is there a bug in Sdl?

SDL Development
1

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Je pense avoir trouv? un bug dans Sdl.

I think I’ve found a bug in Sdl

J’utilise Sdl distribu? avec la Mandrake 9.0

I use the Sdl version distributed with Gnu/Linux Mandrake 9.0

Ca concerne les mutex et les threads

it concernes mutex and thread

Je vous ai joint deux programmes de test, l’un fait avec des threads
Sdl, l’autre fait avec pthread sous Gnu/Linux.

I’ve join two programs. One which uses Sdl threads, the other which

uses pthread thread

Voici le resultat des ex?cutions des deux programmes

here is the resultat of the execution of the two programs

demande : would like go in critical section
acquisition : go in critical section
liberation : end of the critical section

  • ->thread_SDL.c
    1->(demande)
    1->(acquisition)
    2->(demande)
    1->(liberation)
    1->(demande)
    1->(acquisition)
    1->(liberation)
    1->(demande)
    2->(acquisition)
    2->(liberation)
    1->(acquisition)
    1->(liberation)

  • ->thread_linux.c
    bash-2.05b$ ./thread_linux
    1->(demande)
    1->(acquisition)
    2->(demande)
    1->(liberation)
    1->(demande)
    2->(acquisition)
    2->(liberation)
    1->(acquisition)
    2->(demande)
    1->(liberation)
    2->(acquisition)
    2->(liberation)

Vous ne voyez pas encore le probl?me ???

You don’t see the problem ???

Il y a un probl?me de famine !

there is a famine probleme !

1->(demande) : OK
1->(acquisition) : OK
2->(demande) : OK
1->(liberation) : OK
1->(demande) : OK
1->(acquisition) : Attention/Warning !!!

Ce doit ?tre au 2?me thread d’ex?cution la section critique car il l’a
demander en premier, sinon ca risque d’?tre toujours le 1er qui rentre
en section critique

it should be to the 2nd thread to go in critical section because it

has asked in first : otherwise, the 1st thread could always go in
critical section

J’ai ce probl?me dans un jeu que j’?cris avec Sdl

I’ve this bug in a game that I’m writting with Sdl

Merci d’avoir fait Sdl

thanks making Sdl

Nicolas Adenis-Lamarre
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+KwZ9nfTsPKbhHQMRAtEWAJ41xFYmraNCGZt1s8OqOdvwU/9afQCfSNYl
CkLckeBiETlDPCM4oUphTEI=
=ot9p
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed…
Name: thread_linux.c
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20030119/1c90169b/attachment.asc
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed…
Name: thread_SDL.c
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20030119/1c90169b/attachment.txt

2

Vous ne voyez pas encore le probl?me ???

You don’t see the problem ???

Il y a un probl?me de famine !

there is a famine probleme !

1->(demande) : OK
1->(acquisition) : OK
2->(demande) : OK
1->(liberation) : OK
1->(demande) : OK
1->(acquisition) : Attention/Warning !!!

Ce doit ?tre au 2?me thread d’ex?cution la section critique car il l’a
demander en premier, sinon ca risque d’?tre toujours le 1er qui rentre
en section critique

it should be to the 2nd thread to go in critical section because it

has asked in first : otherwise, the 1st thread could always go in
critical section

You actually have a race condition - it’s possible for both threads to
print “(demande)” and then either to actually lock the mutex. In fact,
it’s possible for this sequence to occur:

thread 1: print (demande)
thread 1: mutex lock - success
thread 1: print (acquisition)
– context switch –
thread 2: print (demande)
– context switch –
thread 1: print (liberation)
thread 1: print (demande)
thread 1: mutex lock - success
thread 1: print (acquisition)
– context switch –
thread 2: mutex lock - block
– context switch –
thread 1: print (liberation)
thread 1: print (demande)
thread 1: mutex lock - block
– context switch –
thread 2: print (liberation)
…

What you really want to do to prevent thread starvation is guarantee that
a context switch will occur between the time you unlock the mutex and the
time that you try to re-lock the mutex.

For the record, I see identical behavior between the two programs here.

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment