Je n'ai pas compris la question posée....
J'ai apprécié le livre de David Butenhof Programming With Posix Threads [www.amazon.fr] mais il y a aussi celui de B.Nichols [www.oreilly.com]

Concernant la programmation multi-thread, elle est difficile à mettre en oeuvre, sauf si on se restreint à peu de threads de nature différente... mais j'ai peu codé en multi-thread.

Sous Linux et sous Unix en général, les communications entre processus (notamment pipes, sockets...) marchent vite et bien, et une alternative possible est de développer son application entre plusieurs processus.... De plus, des processus communiquants par échanges de messages peuvent être éventuellement répartis entre plusieurs machines... Et la définition d'un protocole de communication architecture une application en définissant clairement le rôle des développeurs.

Une possibilité est d'avoir un thread ou processus maitre qui sert de moniteur aux autres....

Il y a aussi PVM, MPI, ....

Quelle genre d'application développez vous? Pourquoi avez vous besoin de parallélisme? La grosse difficulté (aussi bien en pthread qu'en multi-processus) c'est l'asychronie, et conséquemment le caractère non reproductible des bogues!

Le style de programmation fonctionnel (comme dans Ocaml ou Haskell) permet aussi d'utiliser des valeurs fonctionnelles d'ordre supérieur, qui organisent agréablement le contrôle (voir aussi le Continuation Passing Style).




----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Tuesday 18 April 2006 23:14:15

D. Monniaux parle pas mal de la sécurité des systèmes critiques dans cette conférence (orientée grand public) et donne son point de vue : [www.diffusion.ens.fr].
Une idée qui se dégage me semble importante à retenir : mettre deux logiciels identiques en parallèle ne sert à rien s'ils travaillent sur les mêmes données, sauf en cas de panne matérielle, puisqu'ils occasionneront les mêmes erreurs. Si le système est vraiment critique et qu'il faut de la redondance, on peut faire développer le programme par deux équipes différentes, ainsi si l'un échoue il y a des chances que l'autre réussisse, ou encore (je ne suis pas sur que ce soit abordé) utiliser un programme de surveillance des processus pour surveiller ceux qui tombent (voire faire tourner ce programme sur un système séparé, c'est je crois l'une des utilisations prévues pour Xen dans le futur même dans les systèmes bureautiques).
La conférence en question est de toute façon à mon avis intéressante, même si on n'a pas vraiment de connaissances sur le sujet (ce qui est mon cas). On y parle aussi beaucoup du projet de Mr. Monniaux, l'analyseur statistique de code Astrée : [www.astree.ens.fr].

[catwell.info]

Poste le Tuesday 18 April 2006 23:34:58

Merci, je connais D.Monniaux et ASTREE (car le labo de sûreté des logiciels du CEA-LIST où je travaille développe des outils sur la même thématique).

Néanmoins, je n'ai pas compris la question du posteur initial.


----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Tuesday 18 April 2006 23:59:39

Je te rassure, moi non plus, pas complètement ... j'ai répondu sur mon interprétation personnelle de ce que pouvait être la question : "Comment éviter / pallier à la défaillance d'applications multi-thread dans un système critique du point de vue sécurité ?".

[catwell.info]

Poste le Wednesday 19 April 2006 00:06:26

Salut à tous et merci déjà de vos réponses ...
Voici un complément d'information alors ;p

Il s'agit d'une application domotique recevant des informations de différentes sources indépendantes (type et moyen de communication) et incertaines (purement asynchrone et pouvant disparaître).
Inversément l'application doit émettre après traitement sur différentes sources avec différents protocoles et moyen de communication.
Chaque type devrait avoir son propre thread, certaines ont une durée de vie illimitée, d'autres limitées dans le temps.
Il me faut que celle qui ont une durée de vie illimitées soient surveillées pour être remontées en cas de non réponse, et le autres surveillées pour qu'elle se coupe après traitement ...

L'applicatif en place perd des threads et/ou certaines se figent.
Je dois éviter ça !!
J'aimerai donc trouver de la documentation sur les méthodes de programmation/analyse de ces problèmes.

L'application n'est pas critique mais il faudrait tendre vers le 95%.

Il ne s'agit pas de mettre deux systèmes en parallèle ça ne servirait pas à grand chose dans notre cas.

Un grand merci à tous !
Je vais déjà jeter un oeil à vos liens ce n'est pas perdu de toute façon LOL
Bonne journée

Poste le Wednesday 19 April 2006 10:08:50

Bah en termes de conception, des systèmes à timeout et watchdogs ça te va ?

------- <br />
La meilleure façon de prédire le futur, c'est de l'inventer ~ Alan Kay

Poste le Wednesday 19 April 2006 14:02:10

J'aimerais d'abord avoir des bonnes méthodes d'analyse et de programmation solides avant de mettre des watchdogs ;o)
Voir d'autres moyens de conception ...

L'idée c'est que le système ne perde aucune info évidemment.

Merci

Poste le Wednesday 19 April 2006 16:23:26

Une application domotique a peut-être moins de contraintes que le système de pilotage d'un Airbus A380 (car j'imagine qu'il n'existe pas d'autorité de certification exigeant des preuves formelles sur votre programme).

Pourquoi ne pas la coder autour d'une simple boucle evenementielle (autour d'un select, ou bien comme celles des toolkits GTK ou QT ou d'un serveur Web)? Si on craint le plantage du système, on pourrait avoir aussi un watchdog (éventuellement matériel).

Mais elle pilote quoi, cette application domotique? Le chauffage, l'electricité, la détection incendie, l'alarme anti-intrusion, l'arrosage anti-incendie? Tout ça a des contraintes de sécurité différentes?

S'agit-il d'une application temps réelle dure, ou juste d'un programme Linux un peu particulier dont on veut qu'il soit assez robuste?

Quelle est la complexité estimée de l'application (10 mille ou 10 millions de ligne de code C)? Quelle est la taille de l'équipe de développement (une paire de collègues dans le même bureau, ou des dizaines de sous-traitants sur des continents différents).... je ne connais rien à la domotique, mais j'imagine que c'est algorithmiquement simple, et que peut-être la majorité du code est l'interface utilisateur et autres gadgets...


Bref, je continue à être dans le flou...

----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Wednesday 19 April 2006 19:07:55

Je pense qu'on est pas vraiment sur la même longueur d'onde ;p

Il y de la détection d'incendie, des poires d'appels d'urgences de personnes ...
Bref oui il faut du presque 100% mais je vois pas pq vous avez besoin de cette info pour me guider dans la programmation propre et le blindage du code.

Il FAUT (impératif) que ça marche peu importe pourquoi c'est une demande du client même si c'était pour piloter son jet automatiquement si les clients le demande il faut du presque 100% ou ils achètent pas ... :-/

Je ne demande pas une analyse du système ça c'est normalement mon affaire ! ];-)
Le workflow n'est pas hyper complexe de toute façon.

Le watchdog c'est bien (et j'en ai déjà fait pour des appl moins critique) mais faut d'abord que le soft soit blindé pour moi !!!!!
Ca ne sert à rien de mettre une béquille sur une jambe de bois !

Qui a déjà programmé ce gendre de soft ?

Poste le Thursday 20 April 2006 10:28:10

Pas moi, et peut-être qu'il n'y a personne sur Léa qui en ait l'expérience de ce genre de choses (c'est assez pointu quand même) ...
Il suffit de regarder l'en-tête de ce forum :

Citation

Pour poser vos questions sur les scripts shell, le Perl, le C, etc... Attention : nous ne sommes pas des spécialistes du dev, ce forum est juste pour de petites aides ponctuelles concernant le développement et les outils de développement.

Il faudrait peut-être poser ta question sur un forum plus spécialisé !

[catwell.info]

Poste le Thursday 20 April 2006 10:49:33

Merci tout de même :-)

Poste le Thursday 20 April 2006 11:28:03

Citation
herachiel
Je pense qu'on est pas vraiment sur la même longueur d'onde ;p

Il y de la détection d'incendie, des poires d'appels d'urgences de personnes ...
Bref oui il faut du presque 100% mais je vois pas pq vous avez besoin de cette info pour me guider
dans la programmation propre et le blindage du code.

Je ne suis pas spécialiste de l'embarqué, mais je travaille (sur l'analyse statique de code) dans un laboratoire de sûreté du logiciel au CEA-LIST, dont les clients principaux sont Airbus (pour le logiciel critique de l'A380) [v]Airbus est très présent en France sur ce domaine, et travaille bien sûr aussi avec l'ENS et le CNRS, et le projet Astrée[/v] et EDF (pour le logiciel critique des centrales nucléaires).

Ici je réponds à titre privé, de chez moi.
Je posais ces questions, parce que le logiciel sûr à 100% exactement n'existe pas, et parce que la sûreté du logiciel oblige à une méthodologie de développement et de validation (notamment en utilisant des outils d'analyse statique) qui existe mais qui est onéreuse et très spécifique.

Donc vous pouvez faire du logiciel très sûr, mais ça sera très cher (ca l'est pour tout le monde). Vous pouvez me contacter sur mon mél professionnel vers monprénom.monnom@cea.fr [v]mon prénom commence par B et mon nom commence par S[/v].

Dans trois ans environ, il y aura probablement des outils en logiciel libre d'analyse statique incorporés ou incorporables dans le compilateur Gnu GCC [v](c'est le projet GGCC que j'ai contribué à initié)[/v].





----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Thursday 20 April 2006 13:59:56

J'ajouterais quand même:

si on cherche des méthodologies de développement pour l'embarqué, il y a une littérature là dessus.
[www.misra.org.uk] [www.ddj.com] [www.cmpevents.com] et google en donnera beaucoup d'autres

si on cherche du conseil en développement, il faut s'adresser à des fournisseurs spécialisés [v]éventuellement le CEA-LIST, mon employeur, ou d'autres[/v] mais ceux ci vendent leur service qui n'est pas gratuit.

Quand à faire du soft robuste, il y a aussi des méthodes, et des règles de codage -dont certaines sont publiques- pour ça.

Mais il ne faut imaginer obtenir gratuitement du conseil pointu (qui prendra beaucoup de travail au consultant) sur la question.... le logiciel libre, ce n'est pas l'esclavage de gens compétents qui travailleraient gratuitement!


----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Thursday 20 April 2006 14:13:17

J'ai oublié d'ajouter une chose importante: vous (càd la société qui vous emploie) auriez intérêt à co-développer en partie votre logiciel critique en logiciel libre, et à vous appuyer sur des standards (y compris futurs, en y contribuant).



----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Thursday 20 April 2006 14:16:04

"Quand à faire du soft robuste, il y a aussi des méthodes, et des règles de codage -dont certaines sont publiques- pour ça. "

C'était ma question initiale !!! ;-);-)

s'appuyer sur des standard c'est un des buts, en log. libre pas encore très facile de faire comprendre au patron LOL

Merci de toutes ces réponses

Poste le Thursday 20 April 2006 14:25:23

Une possibilité serait alors de s'insérer éventuellement dans des initiatives de R&D industrielles, par exemple des projets ITEA [itea2.org] ou RNTL [www.rntl.org] ou IST ou des consortiums métiers.

Et contribuer en partie à des logiciels libres et utiliser ou contribuer au développement de protocoles ou d'API libres est gagnant dans ce genre d'approche.... Ne croyez surtout pas que vous auriez intérêt à publier votre logiciel plus tard; vous avez intérêt à vous insérer dans une communauté dès le départ.

Car il peut s'agit non seulement de s'appuyer sur des standards ouverts, mais aussi de contribuer à les co-développer.... En particulier en domotique, du point de vue du consommateur, l'interoperabilité sera de plus en plus importante, et elle requiert des protocoles ouverts (spécifiés dans des standards publics) qui gagneraient à être implémentés en logiciels libres (par exemple, en LGPL pour la librarie du protocole).

Pour convaincre votre employeur de jouer la coopétition (=coopération + compétition), il faut le faire le plus vite possible, pas quand le projet sera fini!




----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Thursday 20 April 2006 14:46:19

Citation
herachiel
Me citant (Basile "Quand à faire du soft robuste, il y a aussi des
méthodes, et des règles de codage -dont certaines sont publiques- pour ça. "

C'était ma question initiale !!!

Non, la question initiale pourtant sur le multi-threadé. Les règles de codage que je connais portent notamment sur l'embarqué; c'est assez différent!


----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Thursday 20 April 2006 14:55:37