[à propos de la sûreté des langages de programmation] Avec du C c'est tout aussi sur si bien sur on respecte certaines règle.
Je code en C et C++ très régulièrement. En fait, ce sont presque les deux seuls langages que j'utilise. J'écris et j'utilise du code multithreadé à longueur de journée. En fait, une partie de mon boulot consiste à maintenir une bibliothèque pour l'expression de programmes parallèles.
Le C, par définition, n'est pas sûr pour le multi-tâche. Plus exactement, C89 et C99 ne le sont pas, car ils ne savent pas ce qu'est une tâche. C11 a repris le même concept de tâche que C++11, et ça copie plus ou moins les threads POSIX. Bon ben autant dire qu'on est toujours pas dans le « sûr » par défaut.
En fait, l'un des créateurs du modèle mémoire de C++, J.Boehm (quand on suppose un processus séquentiel, pas besoin de modèle mémoire, mais une fois qu'on parle d'un modèle multi-tâches, alors il faut pouvoir décrire les règles de visibilité de lectures/écritures) a même écrit un papier qui s'intitule Threads Cannot Be Implemented as a Library. Un autre, grand expert des modèles d'exécution parallèles, a écrit un excellent article intitulé The Problem With Threads. Dans son papier, il décrit toutes les jolies propriétés liées aux machines séquentielles de Turing. Il explique en quoi c'est extrêmement important pour garantir que les programmes séquentiels sont corrects. Puis il explique comment, dès qu'on a des threads de type PThreads, toutes ces garanties s'envolent par la fenêtre, et qu'il est impossible de prouver qu'un programme multi-threadé est dépourvu de bogues et de race conditions (ou data races). Il propose ensuite un modèle où tout est déterministe par défaut, et seules des régions précises de code sont marquées comme « non-déterministes ». Bref, l'inverse de ce que proposent les threads classiques.
Tout ça pour dire quoi ?
Oui, il est possible d'écrire des programmes concurrents en C/C++ qui font ce qu'on veut
Si on veut faire quelque chose de complexe, il faut un programmeur expert pour le faire correctement
Si un langage de programmation intègre la concurrence directement (Java, Ada par ex), alors il est possible de simplifier la gestion de la concurrence car un ensemble de règles (liées à la mémoire, aux opérations autorisées au sein du programme, etc.) rendront la gestion de la concurrence mieux encadrée.
En règle générale, si quelque chose requiert un expert pour être correctement programmée, alors il faut sans doute qu'elle soit intégrée au langage.
Seule exception à la règle précédente : lorsque le contrôle sur le matériel est un critère dominant dans les pré-requis du projet (et encore, Ada et d'autres langages ont prouvé qu'on pouvait faire du bas-niveau sans sacrifier nécessairement en perfs ou en structures pour le langage...)
[^] # Re: Proust alors.
Posté par lasher . En réponse au journal Ada, langage et ressources. Évalué à 10.
Je code en C et C++ très régulièrement. En fait, ce sont presque les deux seuls langages que j'utilise. J'écris et j'utilise du code multithreadé à longueur de journée. En fait, une partie de mon boulot consiste à maintenir une bibliothèque pour l'expression de programmes parallèles.
Le C, par définition, n'est pas sûr pour le multi-tâche. Plus exactement, C89 et C99 ne le sont pas, car ils ne savent pas ce qu'est une tâche. C11 a repris le même concept de tâche que C++11, et ça copie plus ou moins les threads POSIX. Bon ben autant dire qu'on est toujours pas dans le « sûr » par défaut.
En fait, l'un des créateurs du modèle mémoire de C++, J.Boehm (quand on suppose un processus séquentiel, pas besoin de modèle mémoire, mais une fois qu'on parle d'un modèle multi-tâches, alors il faut pouvoir décrire les règles de visibilité de lectures/écritures) a même écrit un papier qui s'intitule Threads Cannot Be Implemented as a Library. Un autre, grand expert des modèles d'exécution parallèles, a écrit un excellent article intitulé The Problem With Threads. Dans son papier, il décrit toutes les jolies propriétés liées aux machines séquentielles de Turing. Il explique en quoi c'est extrêmement important pour garantir que les programmes séquentiels sont corrects. Puis il explique comment, dès qu'on a des threads de type PThreads, toutes ces garanties s'envolent par la fenêtre, et qu'il est impossible de prouver qu'un programme multi-threadé est dépourvu de bogues et de race conditions (ou data races). Il propose ensuite un modèle où tout est déterministe par défaut, et seules des régions précises de code sont marquées comme « non-déterministes ». Bref, l'inverse de ce que proposent les threads classiques.
Tout ça pour dire quoi ?