Discussion :

[Lsong]

bonjour à tous et à toutes,

je travaille sur un moteur de physique distribué et j'utilise SDL pour la partie thread et donc synchronisation

l'usage des mutex et des sémaphores ne pause pas de problème en soit, c'est trés simple.

SDL_SemWait(sem);
...
SDL_SemPost(sem);

le problème c'est que parfois le sémaphore reste bloquer 16-60 ms sur le wait, alors qu'il n'y a qu'un seul thread !!! Donc je vois mal comment il peu s'auto-interrompre... j'ai vérifié à coup de "cout" le thread ne lance pas deux fois le wait
mais il reste parfois coincé 60ms (environ 1 fois sur 50 appels c'est très variable)
ça arrive une fois de temps en temps mais ça limite les performance de façon assez forte.
Quand j'augmente le nombre de balles dans ma scène le nombre d'appel augmente et les performance s'effondre

sans la synchro je peu gérer 6000 objets en mouvement sur mon 2Ghz
mais avec ces problèmes de sémaphore je ne dépasse pas les 250 ...

c'est un problème connu des sémaphore et mutex SDL ?
c'est un problème d'utilisation ou d'environnement ?
A savoir parfois ce délais est moins fréquent que d'autre.

si quelqu'un a une idée... elle est la bienvenue

[Mat.M]

Pourquoi utiliser des threads dans un jeu il ya eu maintes fois des discussions là-dessus ?
Les threads c'est bon si tu veux faire un jeu multijoeur pour gérer les échanges réseaux...
un "thread"=processus parallèle en bon français c'est un sous-programme ( au sens exécutable binaire pas code source ) qui s'exécute à coté du programme principal ( ceci grace à l'OS et CPU ) donc est-ce vraiment utile ?

[Lsong]

je bosse sur la parallélisation des calculs, et dans le cas présent des calculs de physique.

Sur un monocore je suis à 100% d'accord ca ne sert à rien
vu que les threads se partage la même puissance de calcul.

Sur un Bi-Core ou un Quad-Core ce n'est plus la même chose car on peu utiliser la puissance des 2 ou 4 cores pour les calculs et la il faut faire des threads.

La parallélisation fonctionelle à ses limites du à la différence de charge de chaque process et de la forte dépendance des differentes étape de calculs dans un jeu, le rendu a besoin des calculs de la physique (enfin en général la physique travaille sur la frame suivante).
La je fait de la parallélisation de donnée ce qui est plus difficile dans le cadre d'un moteur de physique, mais ca marche.

Bref tout ca pour dire "oui" je fais des threads en toute connaissance de cause car nous cherchons à exploiter les processeurs multi-core qui devrait devenir courrant d'ici peu.

[fearyourself]

le problème c'est que parfois le semaphore reste bloquer 16-60 ms sur le wait, alros qu'il n'y a qu'un seul thread !!!

Cela n'a pas grand chose à voir je pense puisque :

- Insérer un test pour savoir si on est en mono-thread est inutile puisqu'utiliser des sémaphores dans un code mono-thread est inutile...

- Du coup, avoir un coût avec un seul thread ne me choque pas.

- Ensuite, il est connu que les sémaphores/mutex sont longs à gérer SDL ou Posix d'ailleurs. Il faut : minimiser les appels vers ces fonctions et/ou se débrouiller pour ne pas en avoir besoin...

c'est un probleme connu des semaphore et mutex SDL ?

Je dirais que c'est un problème des mutex/semaphore qui sont mal utilisés du coup, faudrait que tu montres un bout de code...

Jc

[Lsong]

je precise : j'ai testé en mono thread pour voir si j'avais des problèmes de performance, mais le programme "doit" tourner en multi-thread (4 threads car 4 core) donc l'usage des semaphore ou mutex est obligatoire pour ne pas téléscoper les variables commune aux threads.


je peu vous montrer le code
à la base j'ai commencé par des mutex mais comme ils ont le même probleme de performance je suis passer au semaphore qui semble legerement meilleur
mais c'est probablement qu'une impression

void SDL_PContainer::Lock_Mutex(int Mut)
{
SDL_SemWait(vSem[Mut]);
}

void SDL_PContainer::UnLock_Mutex(int Mut)
{
SDL_SemPost(vSem[Mut]);
}

le code appelant dans le thread

pContainer->Lock_Mutex(pContainer->MUTEX_PCZONE_COMPUTE);

if (index>=mZx*mZy)
{
pContainer->UnLock_Mutex(pContainer->MUTEX_PCZONE_COMPUTE);
return false;
}
int _index = ++index; // cette appel ne doit pas etre interompu
pContainer->UnLock_Mutex(pContainer->MUTEX_PCZONE_COMPUTE);

J'ai oté mes codes de debug qui n'apporte pas grand chose (en gros ca lit le temps avant et apres l'appel pour savoir combien de temps c'est ecouler).
La variable index doit être protegé car les threads ont besoin d'avoir une valeur differente à chaque fois.

En gros j'ai un tableau à 2 ou 3 dimension (ca dépend si la scène est en deux ou trois dimension) et les threads doivent traiter chaque case du tableau qui elle même contien un bloque de donnée.
L'index permet de designer une case du tableau différente à chaque increment
le traitement du tableau se fait en //, c'est évidement util que si on a un processeur multi-core biensur.

Sans le semaphore il arrive que deux threads traitent le meme bloque de donnée et ca fini par planter car a la fin du traitement on nettoie les data, donc le thread qui les traite une deuxieme fois crash, de plus une zone ne sera pas traiter ...

bref les threads sont tout à fait reflechie

[fearyourself]

ok question subsidiaire :

Pourquoi ne pas affecter les blocs à la création des threads ?

Tu me réponderas alors sûrement que cela risquerait de faire qu'un thread ne bosse plus pendant que les autres bossent...

A quoi je dirais que cela dépend si tu peux prouver qu'un thread a des chances de tourner plus vite que les autres avec la même charge de boulot.

Sinon, pourquoi ne pas prendre plusieurs blocs en même temps histoire de limiter le nombre de passage dans ce code, tu aurais donc le meilleur des deux mondes...

Jc

[Lsong]

en gros il s'agit de faire les calculs de physique dans la scene, chaque blocs ont une quantité de donner differente, de plus le nombre de bloc depend du nombre d'objet et du volume de la scene
et le traitement doit se faire a chaque frame(le nombre d'objet pouvant changer biensur)

- donc difficile d'allouer les bloc à la creation des threads
- la charge de travaille n'etant pas lineaire par rapport au nombre de bloc ...

cela dit l'idée d'allouer N bloc est possible mais c'est plus un system pour limiter un probleme sans esseyer de le resoudre
de plus j'utilise les semaphore pour proteger d'autre zone ...

quelqu'un sais si les outil win fonctionne bien ? ou je vais avoir le meme probleme
sinon il me reste plus qu'a implementer mes propres outil ?

[Lsong]

je suis aller voir les implementation des mutex et des semaphore SDL
en gros il font un wait par defaut apres le lock

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
int SDL_mutexP(SDL_mutex *mutex)
{
	if ( mutex == NULL ) {
		SDL_SetError("Passed a NULL mutex");
		return -1;
	}
    RMutex rmutex;
    rmutex.SetHandle(mutex->handle);
	rmutex.Wait(); 
	return(0);
}

je ne vois pas c'est quoi un RMutex mais je cherche

[Mat.M]

L'index permet de designer une case du tableau différente à chaque increment
le traitement du tableau se fait en //, c'est évidement util que si on a un processeur multi-core biensur.

Sans le semaphore il arrive que deux threads traitent le meme bloque de donnée et ca fini par planter car a la fin du traitement on nettoie les data, donc le thread qui les traite une deuxieme fois crash, de plus une zone ne sera pas traiter ...

les fonctionnalités de SDL ne sont pas adaptées alors ; il faut utiliser, si tu est sous win32 les sections critiques.
Pour verrouiller index il faut prendre EnterCriticalSection et LeaveCriticalSection mais cela ne sera pas portable sous Linux..

[fearyourself]

je suis bien d'accord que beaucoup de débutants veulent les utiliser à tord, mais ici ça me semble justifié.

Clairement, c'est exactement ce qu'il faut faire dans ce cas précis.

les fonctionnalités de SDL ne sont pas adaptées alors ; il faut utiliser, si tu est sous win32 les sections critiques.
Pour verrouiller index il faut prendre EnterCriticalSection et LeaveCriticalSection mais cela ne sera pas portable sous Linux..

Pas forcément, il n'est pas dit que la SDL n'utilise pas ces appels lorsque c'est compilé sous Windows. Il faudrait regarder le code source pour cela.

Jc

[Laurent Gomila]

es fonctionnalités de SDL ne sont pas adaptées alors ; il faut utiliser, si tu est sous win32 les sections critiques.

Les sections critiques sont plus performantes, mais pas dans tous les cas si mes souvenirs sont bons.
A part ça, pour ce qui est mutex et thread, la SDL ne fait que de bêtes appels aux fonctions Win32 correspondantes, on n'y gagnerait rien à tout recoder.

[hegros]

J'ai oté mes codes de debug qui n'apporte pas grand chose (en gros ca lit le temps avant et apres l'appel pour savoir combien de temps c'est ecouler).
La variable index doit être protegé car les threads ont besoin d'avoir une valeur differente à chaque fois.

Dans ce cas précis tu poses 1 mutex pour protéger l'incrémentation d'une variable alors que pour cela le plus approprié ce ne serait pas les mutex mais les interlocks. Par contre du coup avec SDL je ne connais pas d'équivalent donc voici un lien MSDN

Peut être que c'était pour l'exemple mais je me base sur cela pour répondre.


D'autant plus avec les mutex (idem sémaphore) il faut faire attention à ce que tu ne généres pas de dead lock. C'est à dire qu'a aucun moment tout tes threads ne se retrouvent bloqués et attendent que quelqu'un les débloque.

Normalement un thread qui lock doit délocker lorsqu'il termine la tâche associée (si possible le plus rapidemment possible )

[Lsong]

je suis passer au "section critique" qui font bien leur job
bon les threads se repartissent pas bien le job mais c'est dut au fait qu'il ne se lance pas tous en même temps je suis parti utiliser les Event pour ca, mais ca ne marche pas vraiment
je bosse encore dessu

[hegros]

je suis passer au "section critique" qui font bien leur job
bon les threads se repartissent pas bien le job mais c'est dut au fait qu'il ne se lance pas tous en même temps je suis parti utiliser les Event pour ca, mais ca ne marche pas vraiment
je bosse encore dessu

Pour synchroniser une variable à l'incrémentation, le plus adapté, au risque de me répéter, ce sont les interlocks. Les Events ca fait un peu usine à gaz pour une variable