Comment bien utiliser les mutex ?

[Lolilolight]

Humm, comment que je fais pour voir les variables membres de children[j]

[Lolilolight]

Ha non c'est bon j'ai trouvé quand la taille du vecteur vaut 0 je fais un j-- donc, quand il ne rentre pas dans la boucle, ce qui fait que j vaut -1 mais comme je l'ai déclaré en unsigned int, il ne peut pas valoir -1, du coup, ça plantait.

Je m'attendais quand même à un crash tout le temps au départ même sans lancer le débugueur, comme quoi...

Y'a pas moyen de faire en sorte que le compilateur balance une erreur quand on a un unsigned int qui devient négatif par erreur, j'ai cherché pendant des heures  cause de ça. :/

[Laurent]

Y'a pas moyen de faire en sorte que le compilateur balance une erreur quand on a un unsigned int qui devient négatif par erreur

Nop.

Par contre je peux te donner un conseil : quand ce genre de fonction alambiquée plante, fais une exécution pas à pas avec le debugger, en inspectant les variables locales qui sont utilisées au fur et à mesure. On ne peux pas tout voir simplement en scrutant le code, notamment les cas limites (tableau vide, ...).

Bref, la prochaine fois, au lieu de te précipiter sur le forum pour dire que les mutexs de l'OS sont buggés, que SFML ne marche pas ou autre, prends le temps de faire de vraies session de debugging pour comprendre ce qui se passe dans ton code.

[Lolilolight]

Désolé Laurent j'ai appris à bien programmé. (faire des bons design de code source, des commentaires, des rapports, des diagrammes et tout ce que tu veux mais à aucun moment on m'a appris à me servir du débugueur, chose que j'ai toujours reproché à ma formation.)

Ca avait l'air plutôt d'être des cours du genre : on fait l'analyse, on écris toute la sturcture du code et puis tout le code spécifique au langage de programmation sur papier (enfin au début du moins.) puis on le recopie sur ordinateur et quand on recopie le code sur ordinateur ça doit marcher du 1er coup.

Ce qui était assez absurde, bref..., mais bon voilà maintenant tu sais comment j'ai été formé et on avait pas toujours beaucoup de temps, et tu sais aussi comment ça se passe dans le monde non libre. (c'est à dire dans le monde commercial parce que c'était aussi des études orienté commerce vu que j'étais dans la catégorie économique en informatique de gestion.)
Bref osef de ma vie, cependant j'ai remarqué, pas un bug, ni un crash cette fois mais un beau petit freeze agaçant par moment quand on bouge la vue..., mais ça, ça a déja été dis dans un autre sujet je pense.

Mon personnage parfois arrête de bouger pendant un petit moment. (le FPS ne change pas par contre il est toujours bon.) puis il se tp direct à sa destination. :/)
Y'a des trucs qui ont été modifié dans la SFML 2.1 à propos de ça ou pas ?
Ca me le fait pas tout le temps mais quand même assez fréquement parfois.

[Laurent]

Avoir des lacunes en techniques de debugging, et tout mettre systématiquement sur le dos de SFML et/ou de l'OS, ce sont deux choses très différentes

En ce qui concerne ton problème, non je pense pas que SFML 2.1 y change grand chose. Encore une fois, regarde d'abord ton code avant de chercher l'erreur ailleurs...

[Lolilolight]

Ok Laurent mais je ne vais pas mettre tout sur le dos de mon code source non plus.
Certains OS (je ne coterai pas lesquels.) sont connu pour buguer ou alors freeze à certains moment, je n'ai pas que ce problème avec mon code.

Mais aussi avec d'autres jeux.

De plus il me semble qu'il y a encore quelques bugs ou alors quelques bout de code trop lent avec la SFML, sinon, tu ne referais pas à chaque fois des nouvelles versions.

[Laurent]

Ok Laurent mais je ne vais pas mettre tout sur le dos de mon code source non plus.

Si, c'est au contraire la plus saine des attitudes à avoir. Ce n'est qu'une fois que tu as debuggé à fond et que tu es certain que l'erreur vient d'ailleurs, que tu peux affirmer "c'est SFML / l'OS / xxx qui bug". Mais tant que tu n'es pas sûr à 100% de ton code, alors continue à le debugger.

Moi je dis ça pour toi : en rejetant systématiquement la faute sur SFML ou l'OS tu perds un temps considérable, puisque tu ne fais pas ce qu'il faut pour régler le problème (i.e. debugger ton code).

[Lolilolight]

Ouais, aussi mais là j'ai regardé avec le profiler dans mon code et y'a rien qui semble suspect donc..., ce problème de freeze vient soit de la SFML ou de l'os.

[lefreut]

J'ai essayer de mettre des mutex.lock et unlock dans cette fonction mais ça ne résoud pas le problème.

Tu as un problème d'accès sur une zone mémoire invalide (à priori accès en dehors des bornes d'un tableau). Cela n'a rien à voir avec du multithreading, rajouter des mutex ne va rien changer.

Bon j'ai rajouté ça pour être sur que j ne sois pas plus petit que 0 non plus mais ça ne résous pas le crash, maintenant ça crash tout le temps que ça soit avec le débugueur ou pas.

while (j < children.size() && children[j]->isTraveled())
            j++;
        j--;
        j = (j < 0) ? 0 : j;
 

Si j est un unsigned int, il ne sera jamais négatif (0 - 1 en unsigned int va donner UINT_MAX). Utilise un int.

Au passage si children contient aucun élément, même avec j = 0 ce code est incorrect:
int distMin = children[j]->getCenter().computeDist(finalPos);

[Lolilolight]

Salut, oui j'ai changé mon unsigned int en int et ça marche maintenant. 
Ca n'avais en effet rien à voir avec le multithreading. :/

children[0] contient toujours un élément dans mon cas donc pas de soucis de ce côté là.

[Laurent]

T'as la tête dure hein...

[cobra.one]

ce problème de freeze vient soit de la SFML ou de l'os.

Tu leur diras ça à tes futurs utilisateurs s'il te rapportent un comportement inattendu... ?

Surtout qu'à chaque fois tu finis par découvrir que les bugs viennent de ton code et/ou n'impliquent pas les éléments que tu incriminais au départ.

Alors si tu es aussi sûr du reste de ton code que tu es sûr de ce que tu nous montres... avant d'y trouver des bugs, pas étonnants que tu ais des problèmes, qui à 99% ne viennent ni de SFML et encore moins de l'OS (à moins que tu n'utilisent des algos tellement poussés que tu lèverais à toi seul des bugs qui n'auraient pas été découvert par les millions d'utilisateurs qui utilisent cet OS quotidiennement).

[Lolilolight]

1)Je parle de feeze, pas de bug là.
2)Me redemande pas de retrouver ou ça freeze, parce la programmation de bas niveau ce n'est pas mon fort, la programmation de haut niveau par contre si. (A part que faut juste que je me mette au débuguer parce que les bugs se situent souvent pas là ou je pense.)

[cobra.one]

Oh bah alors si ça frise sans beuguer... tout va bien !

Ce que j'aime c'est ton humilité... m'enfin peut-être as-tu une très solide expérience du développement "de haut niveau" qui te permet ces certitudes, moi tout ce que je sais c'est que si tu pars bille en tête qu'un comportement que tu observes mais ne comprends pas ne peut pas venir de ton code "tellement qu'il est bien pensé dès le départ", tu ne vas pas beaucoup progresser dans ton approche, et ton soft non plus ne risque pas d'évoluer.

Le design, les rapports, toussa c'est super, m'enfin avoir un minimum le nez dans la technique (le "bas niveau") c'est pas mal aussi, ça permet de comprendre certaines choses (pourquoi ça freeze alors qu'il y a sûrement moyen d'éviter ça par exemple), surtout quand on développe un jeu. Ca évite aussi de faire des gros bricolages tous moches pour contourner un problème parcequ'on ne le comprend pas.

Bref je m'éloigne fortement du sujet, je ne peux que te souhaiter de réussir à pondre un soft stable, maintenable et upgradable, les utilisateurs jugeront.

Une dernière anecdote pour la route des fois qu'un éclair de lucidité te traverserait l'esprit : l'autre jour, lors d'une recompilation du soft sur lequel je bosse, le compilo me sort une erreur chelou sur une formule de maths un peu compliquée... alors que syntaxiquement le code était bon. En fait c'était moi qui m'était planté sur une manip' lors de la build, et j'ai mis pas mal de temps à trouver l'erreur. A ma place t'aurais sûrement reporté un bug sur le bugtracker de GCC non ? Genre "Les priorités d'opérateurs ne fonctionnent pas dans certains cas"... ?

En tous cas bonne chance...

[Lolilolight]

Bah comme débugueur j'ai connu mieux..., même si gdb n'est pas bugué, les erreurs sont parfois difficile à repérer.

Celle-ci en tout cas j'ai mis longtemps avant de trouver tout ça parce que j'avait la valeur INT_MAX et donc que je dépassait les limites de mon std::vector.

Hors que en java par exemple j'aurai eu un ArrayIndexOutOfBoundException bref...

Prochaine fois je me retiendrai de ne pas faire un post en disant que c'est un bug avec les thread hors que ce n'est pas le cas désolé.

PS : j'aimais bien le java auparavant et je pensais passé à un seul langage pour le site web et le mon soft mais j'ai changé d'avis par la suite car je me suis rendu compte que ça ne marchait pas vraiment toujours très bien, bref, en tout cas j'avais plus de difficulté avec JOGL que avec la SFML car problèmes d'accès coucurrents avec JOGL et problème aussi avec JEE.
(Bref plus de lacunes dans le domaine surement.)
Je ne peux malheureusement pas mélanger les outils des 2 langages. (gdb pour le c++ et le débugueur java sous éclipse.)
Tout du moins je pense pas, maintenant si y'a moyen de le faire je serai intéressé mdr.

PS : et puis bon je me suis rendu compte que les méthodes des librairies ne sont pas toujours thread safe ce qui parfois pose des problèmes, surtout quand la librairie utilise des threads en interne, bref, c'est ce qui s'appelle, la misère qu'on a avec les nouvelles technologie.