existe-t-il un langage à l'épreuve des catastrophes?

Question

Lors de la création du système de services, qui doit avoir un haut niveau de fiabilité, j'ai souvent écrit beaucoup de "failsafe" mécanismes dans le cas des choses comme: les communications qui ont disparu (par exemple la communication avec la DB), qu'arriverait-il si le pouvoir est perdu et le redémarrage du service.... comment ramasser les morceaux et continuer dans le bon sens (et de se rappeler que tout en ramassant les pièces de la puissance pourrait sortir encore une fois...), etc etc

Je peux imaginer pour ne pas avoir trop de systèmes complexes, une langue qui ne leur répondre ce serait très pratique. Donc, une langue qui ne se souvenir de son état à un moment donné, peu importe si l'alimentation est coupée, et continue là où il l'avait laissé.

N'existent pas encore? Si oui, où puis je le trouver? Si non, pourquoi ne peut-il être réalisé? Il me semble très pratique pour les systèmes critiques.

p.s. Dans le cas de la DB de perte de connexion, cela voudrait dire que cela pose un problème, et une intervention manuelle est nécessaire. Au moment où il connexion est rétablie, il serait de continuer là où il l'avait laissé.

EDIT: Depuis la discussion semble être mort, laissez-moi d'ajouter quelques points(en attendant, avant que je puisse ajouter une prime à la question)

L'Erlang réponse semble être évalué supérieur droit maintenant. Je suis conscient d'Erlang et avoir lu la pragmatique livre par Armstrong (le principal créateur). Il est très joli (bien que les langages fonctionnels me fais tourner la tête avec tous les récursivité), mais la "tolérance de panne" bit ne vient pas automatiquement. Loin d'elle. Erlang offre un grand nombre de superviseurs en d'autres méthodologies pour superviser un processus, et de le redémarrer si nécessaire. Cependant, pour bien faire quelque chose qui fonctionne avec ces structures, vous avez besoin d'être très à l'erlang gourou, et la nécessité de mettre votre logiciel de s'adapter à tous ces cadres. Aussi, si les chutes de tension, le programmeur a trop de ramasser les morceaux et essayer de récupérer la prochaine fois que le programme redémarre

Ce que je cherche est quelque chose de beaucoup plus simple:

Imaginez une langue (en tant que simple comme PHP par exemple), où vous pouvez faire des choses comme faire les requêtes DB, loi sur les, effectuez les manipulations de fichier, effectuez dossier manipulations, etc.

C'est la principale caractéristique, cependant, devrait être: Si la batterie meurt, et que la chose redémarre, il prend de l'endroit où il l'avait laissé (il ne se souvient pas où il était, il se souviendra de la variable d'états). Aussi, si il s'est arrêté au milieu d'un filecopy, bien résumé. etc etc.

Dernière mais pas moins, si la connexion aux bases de gouttes et ne peut pas être restaurée, la langue tout s'arrête, et les signaux (syslog peut-être) pour l'intervention de l'homme, et l'emporte alors sur l'endroit où il l'avait laissé.

Une langue comme ce serait faire un grand nombre de services de programmation beaucoup plus facile.

EDIT: Il me semble (à en juger par tous les commentaires et réponses) qu'un tel système n'existe pas. Et ne sera probablement pas dans un proche avenir prévisible en raison de sa (proche?) impossible d'obtenir le droit.

Trop mauvais.... encore une fois je ne suis pas à la recherche de cette langue (ou cadre), pour me mettre à la lune, ou l'utiliser pour surveiller quelqu'un à la fréquence cardiaque. Mais pour les petites prestations périodiques et à des tâches qui finissent toujours par avoir des tonnes de code de la manipulation bordercases (powerfailure quelque part au milieu, des connexions de tomber et de ne pas remonter),...où une pause ici,...corriger les problèmes,....et de continuer là où vous l'avez laissé approche qui fonctionne bien.

(ou un point de contrôle d'approche comme l'un des commentateurs ont fait observer (comme dans un jeu vidéo). Définir un point de contrôle.... et si le programme meurt, redémarrez ici la prochaine fois.)

Bounty attribués: À la dernière minute quand tout le monde était venue à la conclusion qu'il ne peut pas être fait, Stephen C est livré avec napier88 qui semble avoir les attributs que je cherchais. Même si c'est un expérimentales de la langue, il ne se prouver qu'il peut être fait et il est une chose qui vaut la peine d'étudier plus.

Je vais être à la recherche à la création de mon propre framework (avec la persistance d'un état et d'instantanés peut-être) pour ajouter les fonctionnalités que je suis à la recherche pour en .Net ou une autre VM.

Tout le monde merci pour l'entrée et les grandes intuitions.

Answer 1

Erlang a été conçu pour une utilisation dans les systèmes de Télécommunications, où la haute-rel est fondamentale. Je pense qu'ils ont méthodologie standard pour les jeux de construction de communiquer des processus dans lesquels les échecs sont normalement traitées.

ERLANG est un simultanées fonctionnelle de la langue, qui convient bien pour la distribution, très simultanées et à tolérance de panne de logiciel. Une partie importante de Erlang est son soutien pour la récupération de défaillance. La tolérance aux pannes est fourni par l'organisation de processus d'une ERLANG application dans les structures en arbre. Dans ces structures, parent surveillance des processus les échecs de leurs enfants et sont responsables de leur redémarrage.

Answer 2

Logiciel de la Mémoire Transactionnelle (STM) combiné avec la RAM non volatile serait probablement satisfaire les OP révisée de la question.

La STM est une technique pour poser les "transactions", par exemple, d'un ensemble d'actions qui sont accomplies de manière efficace comme une opération atomique, ou pas du tout. Normalement, le but de la STM est de permettre hautement parallèle des programmes d'interagir sur le partage des ressources d'une manière qui est plus facile à comprendre que la serrure traditionnelle-que-ressource de programmation, et a sans doute moindre frais généraux en raison d'avoir un très optimiste sans verrouillage de style de programmation.

L'idée fondamentale est simple: toutes les lectures et écritures à l'intérieur d'une "transaction" bloc sont enregistrées (en quelque sorte!); si deux threads conflit sur le ces ensembles (lecture-écriture ou en écriture-écrire des conflits) à la fin de leurs opérations, dont l'un est choisi comme le gagnant et le produit, et l'autre est forcé de revenir à son état au début de la transaction et de ré-exécuter.

Si l'on a insisté pour que tous les calculs ont été des opérations, et l'etat au début/à la fin) de chaque transaction a été stocké dans la mémoire vive non volatile (NVRAM), une coupure de courant pourrait être considéré comme une opération de l'échec résultant en un "rollback". Les calculs de procéder uniquement à partir traitées états de manière fiable. La NVRAM de ces jours peut être mis en œuvre avec la mémoire Flash ou avec batterie de secours. On pourrait avoir besoin de BEAUCOUP de mémoire NVRAM, comme les programmes ont beaucoup de l'etat (voir mini-ordinateur histoire à la fin). Sinon, commis de l'état des modifications qui pourraient être écrites dans des fichiers journaux qui ont été écrits sur le disque, c'est la méthode standard utilisée par la plupart des bases de données et par des systèmes de fichiers.

La question en cours avec la STM est, comment cher est pour garder une trace de la transaction potentielle de conflits? Si la mise en œuvre de la STM ralentit l'ordinateur par un montant appréciable, les gens vont vivre avec l'existant légèrement fiable régimes plutôt que de renoncer que de la performance. Jusqu'à présent, l'histoire n'est pas bon, mais alors la recherche est précoce.

Les gens n'ont généralement pas conçu langues STM; à des fins de recherche, ils ont pour la plupart amélioré Java avec la STM (voir les Communications de l'ACM article en juin? de cette année). J'entends MS a une version expérimentale de C#. Intel a une version expérimentale pour le C et le C++. La page de wikipedia a une longue liste. Et la programmation fonctionnelle, les gars sont, comme d'habitude, affirmant que le sans effets secondaires propriété de programmes fonctionnels rend STM relativement simple à mettre en œuvre dans les langages fonctionnels.

Si je me souviens bien, dans les années 70 il y avait beaucoup de début de travail dans la répartition des systèmes d'exploitation, dans lequel les processus (code+état) pourrait voyager trivally de machine à machine. Je crois que plusieurs de ces systèmes explicitement autorisé défaillance d'un nœud, et pourrait redémarrer un procédé dans un nœud défaillant à partir d'enregistrer l'état d'un autre nœud. Début des principaux travaux ont été sur la Le Calcul distribué Système par Dave Farber. Parce que la conception de langages de retour dans les années 70, était populaire, je me souviens de DCS a il avait son propre langage de programmation, mais je ne me souviens pas le nom. Si les PED n'ont pas permis une défaillance d'un nœud et de redémarrer, je suis assez sûr de le suivre sur les systèmes de recherche en fait.

EDIT: en 1996, UN système qui apparaît au premier coup d'œil pour avoir les propriétés que vous désirez est documenté ici. Son concept d'opérations atomiques est cohérent avec l'idée qui est derrière la STM. (Va pour le prouver il n'y a pas beaucoup de nouveau sous le soleil).

Une note de côté: de Retour dans années 70, Core Mémoire était encore roi. De base, étant magnétique, a été non volatile à travers de panne, et de nombreux mini-ordinateurs (et je suis sûr que les mainframes) a eu coupure de courant interrompt qui a notifié le logiciel de quelques millisecondes avant de perte de puissance. En utilisant cela, on pourrait facilement stocker le registre d'état de la machine et de l'arrêter complètement. Quand le courant a été rétabli, le contrôle de revenir à un point de restauration, et le logiciel pourrait procéder. De nombreux programmes peuvent donc survivre alimentation clignote de manière fiable et redémarrer. Personnellement, j'ai construit un système de partage du temps sur des Données Générales Nova mini-ordinateur; vous avez en cours d'exécution 16 télétypes à plein régime, prendre un hit en puissance, et de revenir et de redémarrer tous les télétypes comme si de rien n'était. Le changement de la cacophonie au silence et à l'arrière est superbe, je sais, j'ai dû répéter plusieurs fois pour le débogage en cas de panne du code de gestion, et il a bien entendu fait une grande démonstration (tirez sur la fiche, un silence de mort, rebranchez...). Le nom de la langue qui l'a fait, était, bien sûr, Assembleur :-}

Answer 3

De ce que j'ai know1, Ada est souvent utilisé dans les critiques de sécurité (failsafe) des systèmes.

Ada a été initialement ciblées à embarqués et systèmes temps-réel.

Caractéristiques notables de l'acl: taper fort, la modularité des mécanismes de (forfaits), au moment de l'exécution de la vérification, le traitement parallèle (tâches), exception la manipulation, et les génériques. Ada 95 ajouté soutien pour l'orienté objet de programmation, y compris les dynamiques de l'expédition.

Ada prend en charge au moment de l'exécution de contrôles pour protéger contre l'accès à non alloué de la mémoire, de dépassement de tampon des erreurs, tout-en-un d'erreurs, tableau les erreurs d'accès, et d'autres détectable des bugs. Ces vérifications peuvent être désactivés dans l'intérêt de l'exécution de l'efficacité,de mais peut souvent être compilées de manière efficace. Il comprend également des installations pour les aider programme de vérification.

Pour ces raisons, Ada est largement utilisé dans les systèmes critiques, où toute anomalie peut entraîner de très graves les conséquences, c'est à dire, en cas de décès accidentel ou d'une blessure. Exemples de systèmes où Ada est utilisé notamment les systèmes d'avionique, de l'arme les systèmes (y compris thermonucléaire les armes), et des vaisseaux spatiaux.

N-Version de programmation peut également vous donner quelques conseils de lecture de référence.

1C'est en fait une connaissance qui écrit embarqués critiques pour la sécurité, logiciel de

Answer 4

Je doute que les possibilités de la langue que vous décrivez sont possibles à réaliser.

Et la raison en est qu'il serait très difficile de définir commun et général des modes de défaillance et comment en guérir. Penser une seconde au sujet de votre exemple d'application - un site web avec un peu de logique et de base de données access. Et disons que nous avons une langue qui peut détecter l'arrêt de l'alimentation et de démarrage ultérieur, et en quelque sorte de s'en sortir. Le problème est qu'il est impossible de connaître la langue comment faire pour récupérer.

Disons que votre app est une application de blog. Dans ce cas, il peut être suffisant de simplement continuer à partir du point nous avons échoué et tout sera ok. Toutefois considérer scénario similaire pour une banque en ligne. Tout à coup, il est plus intelligent de continuer à partir du même point. Par exemple, si j'essayais de retirer de l'argent de mon compte, et l'ordinateur est mort juste après les contrôles, mais avant le retrait, et il retourne alors une semaine plus tard, il va me donner de l'argent même si mon compte est dans le négatif maintenant.

En d'autres termes, il n'y a pas qu'une seule bonne stratégie de récupération, donc ce n'est pas quelque chose qui peut être mis en œuvre dans le langage. Quelle langue peut faire est de vous dire quand quelque chose de mauvais arrive - mais la plupart des langues déjà qu'avec les mécanismes de gestion des exceptions. Le reste, c'est aux concepteurs d'application à penser.

Il y a beaucoup de technologies qui permettent la conception de tolérance de pannes des applications. Transactions de base de données, durable files d'attente de messages, de clustering, de matériel chaud et ainsi de suite et sur. Mais tout dépend des exigences et la façon dont beaucoup de l'utilisateur est prêt à payer pour tout cela.

Answer 5

Il y a l'expérimentation d'un langage appelé Napier88 qui (en théorie) a certains attributs de la catastrophe-la preuve. La langue prend en charge Orthogonale de la Persistance, et dans certaines implémentations, cela s'étend (extended) pour inclure l'état de l'ensemble du calcul. En particulier, lorsque le Napier88 système d'exécution de l'enregistrement pointé une application en cours d'exécution à la persistance de la boutique, le thread courant de l'état serait inclus dans le point de contrôle. Si l'application avant de s'écraser et de le redémarrer dans le droit chemin, vous pourriez reprendre le calcul à partir du point de contrôle.

Malheureusement, il y a un certain nombre de questions difficiles qui doivent être résolus avant que ce genre de technologie est prête pour utilisation courante. Ces inclure essayer de comprendre comment support multi-threading dans le contexte de orthogonale de la persistance, à comprendre comment permettre à plusieurs processus partagent un magasin persistant et évolutif de collecte des ordures de la persistance des magasins.

Et là est le problème de faire Orthogonale de la Persistance dans une langue dominante. Il y a eu des tentatives visant à faire de l'OP en Java, y compris celui qui a été fait par des gens associés avec le Soleil (le Pjama projet), mais il n'y a rien d'actif à l'heure actuelle. Le JDO / Hibernate approches sont les plus favorisées de ces jours.

---

Je tiens à souligner que Orthogonale de la Persistance n'est pas vraiment la catastrophe-la preuve au sens large. Par exemple, il est impossible de traiter:

• le rétablissement de connexions, etc avec "l'extérieur" des systèmes après un redémarrage,
• demande de bugs que de provoquer la corruption de données persistantes, ou
• la perte de données à cause de quelque chose à faire tomber le système entre les points de contrôle.

Pour ceux-ci, je ne crois pas qu'il existe des solutions générales qui serait pratique.