J'ai un leger soucis avec mon code. Lorsque je le fais tourner à fond (100%cpu), une exception (n°5 d'apres le rapport) se déclenche apres environ 10 minutes. Ce qui doit correspondre au segfault.
 
Mon code est compilé/linké en release avec le libs Boost en version release. Il n'y aucune IHM. J'ai l'impression que l'anomalie tourne autour de cet objet :

Je ne vois pas (pis j'ai mangé trop de gateau, ça ralentit le cerveau). Ceci dit, tu fais un notify alors même que tu as encore le lock, donc ça peut lui déplaire et te causer des trucs étranges.  
 
Peux-tu essayer comme ça:

 
A défaut, quel est le type de X, et où le code plante-t-il ?

Je realise la modification et je me reviens vers toi.
 
X est un vector<unsigned char>.
 
Je n'ai précisement aucune technique pour le debug de ce type de code à plusieurs threads. Je ne serais donc pas dire ou le code plante...

Tu es sous quel environnement ? (OS, compilo, etc.). Tu as déjà du le dire, mais j'ai une de ces flemmes de chercher...

Je travaille sous windows Xp sp 2, et je compile avec MinGW 2.0 (gcc3.2).

Si tu as gdb, tu dois être capable d'avoir les frames de ton truc (il le fait sous cygwin, donc sous mingw, ça doit le faire aussi). Pense juste à compiler avec -g.  

En effet, MinGW est fourni avec un outil de debug qui remplace DrWatson. Je constate donc que mon code plante systématique à l'appel des composants logiciels de Boost::Thread (mutex et condition). Comme Boost est fiable, j'en déduis que mon compilo a réellement un pb (configuration multi threading peut etre pas activée). JE vais recompiler avec Visual ou autre.
 
A tout hasard, sais tu comment compiler ce type de code sous GCC/MinGW (ligne de commande) ?

moi j'ai jamais compris ces trucs
 
end = ( end + 1 ) % circular_buf.size();
 
si la taille n'est pas un multiple de 2, mieux vaut faire un pauvre if , c'est plus rapide.
 
 
file du code compilable (classe + programme de test) tant qu'à faire si tu as des doutes

pour moi il n'y a pas besoin de scoper le lock plus que ça, la définition me semble correcte. je dirais même le contraire. une condition est associée à un lock, il faut demander le verrou dessus tant qu'on la manipule

C'est bien ce qui m'embête: le code est correct, et je dirais même canonique: c'est typiquement comme ça qu'il faut faire.  
 
Ceci dit, je ne fais pas 100% confiance au couple Boost/Mingw.
 
Donc le truc était de vérifier si ça marchait mieux en laissant le notify prévenir les classes sans que le lock ne soit actionné (pour qu'elles puissent sortir sans encombre du wait() ).
 
Xterm, sous Mingw, as-tu essayé "-pthread -mthreads" comme option de compil ?

pour moi aussi. c'est pour ça que j'aimerais bien avoir du code compilable + main de test qui montre la défaillance

Sans modifier le code source, j'ai mis à jour le compilateur. J'ai aussi recompilé le code avec l'option "-mthreads" (btw, l'option "-pthread" n'est pas reconnue). Je n'ai pas recompilé les librairies Boost.Thread (les dll multithread en paritculier). J'ai relinké mon programme.
 
A prendre avec des pincettes (les bugs de ce type sont traitres), le code tourne depuis une heure sans plantage avec 2 ou 3 threads en plus du main.

ça peut ne pas planter tout en violant l'exclusion mutuelle

Fous des traces, je pense que ça peut aider.

Apres une douzaine d'heure de test intensif, je n'ai pas eu un seul crash. Je respire enfin ! Tout semble fonctionner correctement.    
 
Je conseille donc à ceux qui utilisent MinGW de mettre leur compilateur à jour en téléchargeant les packages individuels. La version de MinGW en une seule archive et celle fournie avec MinGW Studio ne sont pas fiable pour la programmation multithreads.
 
Merci de votre aide.  

Je viens de voir que tu compilais avec gcc 3.2 ? Tu es tjrs sous gcc 3.2 ? Il me semble avoir lu qq part que cette version était assez moisie (de façon générale les versions entre la 2.96 et la 3.3.1, il me semble que c'est pas génial, qq peut confirmer ? Taz ?).

Clair. Je me demande comment j'ai pu coder autant (dont quelques services winNT multithreads) avec cette version antérieure qui semble peu recommandable !

elle l'est pas mais elle a pas vécu très longtemps. t'as qu'à filer ton code, que je teste avec g++-3.3, g++-3.4 et g++-3.5

3.0 et 3.1 pas digne de faire du code "commercial", c'est mon avis. C'est surtout les optimisateurs qui étaient vraiment moisis. Et du code fortement STL sans optimisation du compilo, c'est de la bouse. Bref le compilo était presque inutile.
 
Là, je suis sous la 3.3.3 sous cygwin, et ça a l'air correct, à part les messages d'erreur qui sont à se pisser dessus, mais bon on a ce qu'on paye.
 

il faut utiliser stlfilt et ça roule. Les messages sont long et verbeux, certes, mais nécessaires à une analyse fine. Même si tu payais, le message ne pourrait pas être meilleur : y a des échecs d'instantiation, il faut affiche le tout déroulé. Je sais pas comment fait VC, mais je vois mal comment on peut simplifier le message sans perdre d'information.

est mieux formaté, mais ne change pas en substance

Y des scripts sympas pour VC++ qui "remplacent" le compilo et qui font l'équivalent d'un stlfilt.  
 
Mais je ne pensais pas à ça, je pensais à la qualité des messages d'erreur sous Forte (facile à parser, clairs, précis à la colonne près), et les espèces de truc que sort g++, plus proche du "syntax error somewhere".
 
Genre, j'ai eu le malheur d'installer wxWidgets qui m'a françisé le truc à moitié:

ouais alors forte, moins je bosse avec, mieux je me porte. c'est antédéluvien.

Le front-end est pas mauvais, et l'optimiseur est carrément solide. Par contre, la gestion des templates est catastrophique, c'est clair.  
 
Le template-repository, il ressemble à un truc codé par un stagiaire.

même au niveau du C, c'est la marne. Je sais pas ce que c'est la politique de licence de Forte, mais sur les Solaris surlesquels je bosse, y a tous les gcc récents contre la version de base fournie ...