Discussion :

[peijnoob]

Bonjour à tous,

Nous avons développé pour un client une application, basée sur une API.

Les utilisateurs travaillent sur une applet JAVA, ils y saisissent des commandes (l'applet ressemble à une sorte de prompt). A travers l'API, nous récupérons les commandes qu'ils saisissent à l'aide de callbacks, et effectuons des actions en fonction de ces commandes (comme envoyer des messages sur l'écran de l'applet).

Nous sommes obligés d'utiliser divers threads pour gérer certaines de ces actions, sinon, nous bloquons totalement l'API (pas uniquement le temps du traitement).


Passons au vif du sujet : jusqu'à la semaine dernière, il n'y avait aucun souci.
Seulement, le parc informatique de notre client a été récemment mis à jour, et ils ont maintenant des machines bien plus véloces.
Depuis, des erreurs bizarres ont commencé à faire leur apparition : nous avons de temps en temps droit au fameux "une erreur système inattendue est survenue", ou encore Windows qui prends les devants avec un joli "L'application blabla.exe a rencontré un problème et doit fermer", ou encore un joli "pure virtual function call" du runtime distribuable visual c++.

Ces messages d'erreur me sont plutôt familier, étant donné que je les ai croisé maintes fois lors des plantages de Windev pendant les développements...


Enfin, après avoir réfléchi à l'origine du problème, je me suis demandé si cela ne pouvait pas venir du fait que l'application soit multithread.
Je suis dans l'obligation d'utiliser quelques variables globales pour gérer certaines valeurs qui peuvent être modifiées dans un thread et lues dans un autre.
Je me demandais donc si la source du problème pouvait venir du fait qu'un des threads essaie de lire un variable, et qu'au même moment, un autre thread essaie d'écrire dans cette même variable ?

Dois-je mettre en place des fonctions de lecture et d'écriture pour ces variables que je protègerais à l'aide de sémaphores ?

Est-ce que je suis totalement à côté de la plaque ?


J'attends avec impatience vos commentaires et impressions face à ce problème.

[tatayo]

Bonjour,
Je ne sais pas si les messages d'erreur viennent de là, mais il est clair que si deux threads (ou plus) accèdent à la même ressource (ici des variables), il faut protéger ces accès via des sémaphores.

Une autre solution (un peu lourde à mettre en place il est vrai) peut être d'utiliser un objet global à la place de variables globales, d'acceder au propriétés de cette objet via des méthodes, et d'encadrer les dites méthodes avec des sections critiques (où bien sûr d'utiliser des sémaphores).
L'avantage de cette solution est que le "code de protection" n'est qu'à un seul endroit, aucun risque de l'oublier...

Tatayo.

[peijnoob]

Les sémaphores me paraissent plus intéressantes que les sections critiques car elles sont partagées par tout le projet, et ça m'a l'air plus flexible.

Enfin, je vais m'atteler à la tâche, tout ceci va être tout de même assez ardu

[Edouard Kaiser]

Il y a effectivement de très fortes chances que tes problèmes viennent de la. Quand différent threads accèdent à la même ressource (lecture/écriture), il faut obligatoirement vérouiller les accès à la ressource (par les sémaphores par exemple). Sinon, résultat aléatoire garanti...

[peijnoob]

Donc, j'ai créé une classe, avec plein de membres et de méthodes statiques en lieu et place des variables globales.

J'ai créé des accesseurs pour chaque membre qui gèrent les sémaphores afin d'éviter les accès concurrents.

RAS au niveau des tests, j'ai fait la MAJ chez le client histoire de voir si ça va mieux.

Je vous tiens au courant, merci pour les conseils !

[peijnoob]

Alors après retours du client, le problème n'était pas résolu.

Un peu déçus du résultat, nous avons continué à creuser et j'ai repensé à des essais que j'avais fait sur un projet de test, qui m'avait montré quelques bugs au niveau des traces en multithread.

Or, j'ai laissé la fonction de trace, en mode fichier, dans mon application car elle est en phase des tests chez nos clients, et c'est encore utile à des fins de débugguage.
Et là, j'ai réalisé que les problèmes venaient certainement du fait que plusieurs threads essayaient d'écrire dans le fichier en même temps, et là, forcément, ça coince !!

Du coup, j'ai temporairement désactivé la fonction de trace dans l'appli en attendant d'écrire une fonction protégée, et je n'ai eu que des retours positifs toute l'après-midi, donc j'ai bien l'impression qu'on tient notre coupable !!


Je marque le sujet comme résolu donc, merci encore à tous pour vos lumières