Quelle serait la meilleure façon de gérer les erreurs dans les programmes parallèles?

Avec des algorithmes parallèles frappant à la porte, ce pourrait être un bon moment pour penser à la gestion des erreurs.

Donc, au début, il y avait des codes d'erreur. Ceux-là étaient nuls. Il était libre de les ignorer, vous pourriez donc échouer tard et produire du code difficile à déboguer.

Viennent ensuite les exceptions. Celles-ci ont été rendues impossibles à ignorer une fois qu'elles se sont produites, et la plupart des gens (sauf Joel) les aiment mieux.

Et maintenant, nous avons des bibliothèques qui aident le code parallèle. Le problème est que vous ne pouvez pas gérer les exceptions dans le code parallèle aussi facilement que vous le pourriez avec du code non parallèle. Si vous lancez une tâche de manière asynchrone et qu'elle déclenche une exception, il n'y a aucune trace de pile au-delà pour se détendre; le mieux que vous puissiez faire est de le capturer et de l'enregistrer sur l'objet de tâche, s'il existe un tel objet. Cependant, il vainc la force principale des exceptions: vous devez les vérifier et vous pouvez les ignorer sans effort supplémentaire , alors que dans le code à thread unique, une exception déclenchera nécessairement les actions appropriées (même si cela signifie mettre fin à votre programme).

Comment les implémentations de langage ou les bibliothèques doivent-elles prendre en charge les erreurs dans le code parallèle?

programming-languages parallelism exceptions

— zneak
source

Cela ne devrait-il pas appartenir à stackoverflow ?

— Graviton

@Ngu Soon Hui C'est subjectif et il s'agit de fonctionnalités qui n'existent pas nécessairement, donc je pense qu'il appartient ici.

— zneak

Mais il s'agit de programmation, pas de programmeurs. :)

— bzlm

@bzlm FAQ indique: "Programmeurs - Stack Exchange est destiné aux programmeurs experts qui sont intéressés par des discussions subjectives sur le développement de logiciels." et SO décourage explicitement les discussions subjectives.

— zneak

Réponses:

J'aime plutôt les rappels d'erreurs qui peuvent être traitées. Et ils peuvent être faits pour fonctionner très bien de manière asynchrone ...

Mais pour les erreurs qui ne peuvent pas être gérées, les erreurs vraiment exceptionnelles , je préfère voir les informations pertinentes enregistrées et le programme terminé. Comme cela est généralement accompli via une sorte de gestionnaire d'erreurs global de toute façon, je ne vois pas la nécessité de transformer les exceptions en quelque chose qui fonctionne pour cela - mais un meilleur support de plate-forme pour détecter les erreurs critiques et produire des vidages de mémoire, etc. serait bien.

— Shog9
source

Je second rappels. L'idée ci-dessus me semble assez parfaite.

— Pax Noctis

-2

Il semble que vous souhaitiez vous assurer que la tâche a géré ses propres exceptions, puis renvoyer quelque chose qui indique au programme appelant que le thread doit être arrêté. Il serait alors logique de traiter le résultat de tous les threads, sachant que certains de ces threads ont échoué.

"rendre quelque chose" - à qui? L'appelant est déjà passé.

— Mark H

Comme l'a dit @sparkie, vous ne pouvez pas simplement faire cela. Même si vous conservez la pile d'appels comme racine pour la coroutine, l'appelant sera probablement très loin. Comme je l' ai mentionné, des exceptions ont été conçues de sorte qu'ils arrêtent votre programme , maintenant . Le vérifier vous-même le vaincra plus tard, car les exceptions pourraient passer inaperçues.

— zneak

@Zneak, je suppose que lorsque j'ai mentionné des exceptions, je n'utilisais pas votre définition (standard), je voulais simplement dire que l'erreur a été détectée. Une fois qu'une fonction est terminée, elle doit retourner quelque part, à ce stade, "l'exception" / l'erreur peut être traitée (à ce niveau). Je ne sais pas pourquoi vous faites référence au programme appelant étant éloigné, toute valeur de retour de la fonction doit être traitée d'une manière ou d'une autre. Je me rends compte que cela ne fonctionnera pas aussi bien si les résultats des threads se maillent de manière dépendante.

Toutes les tâches parallèles ne "reviennent" pas quelque part. Par exemple, vous pouvez simplement déléguer une longue tâche à un thread séparé tout en faisant autre chose sur le thread principal (à tort) sans jamais vous demander si elle s'est terminée correctement. Par exemple, je pourrais écrire un logiciel d'édition d'image qui écrit dans des fichiers à partir d'un thread secondaire et revenir de la boîte de dialogue d'enregistrement dès que la tâche est lancée. Je n'aurai pas besoin de la valeur de retour, quelle qu'elle soit, pour toute autre opération, donc à l'exception des erreurs, il n'y a aucune raison de la vérifier.

— zneak