Bonjour a tous !  
je suis sur un projet qui necessite de traiter des images sur un systeme embarqué sur lynxos le plus rapidement et le plus securitairement possible (pas de plantage permis ). Bien sur chaque partie du traitement est modulaire et donc on a separé le code en "processus",  il y a une grosse partie de comunication interprocess mais aussi avec les capteurs de vision,  
 
Une grosse question se pose a moi ...
 
Dois-je partir sur un devellopement multithread ou multiprocess ? , Bien entendu le traitement linéaire n'est pas permis, la reception de donnée doit etre immediate ..etc...
J'aimerai avoir votre avis sur les pour et les contres de chacune de ces solutions aussi bien dans un cas general que des raisons spécifiques au temps réel et avec l'idée que vous pouvez vous faire de mon projet
 
Merci d'avance les gens  
 
--  
Touny

je vais relancer on sais jamais ....

Multithread : espace mémoire partagé donc plus risqué pour la fiabilité mais plus simple à mettre en oeuvre et plus rapide.
Multi-process : espace mémoire protégé mais il faut gérer une communication inter-process (mémoire partagée, pipe,  autre...).
 
A toi de définir la priorité : perfs ou sécurité?

si l'application ne doit pas planter, faut que le code soit blindé, donc autant partir sur les threads, ce sera beaucoup plus rapide, surtout pour faire du temps réél.

C'est le contraire, pour avoir une application blindée il faut le plus possible éviter le modèle mémoire partagée + sémaphores, source de race conditions et autres deadlocks.
 
C'est pourquoi quand le labo de recherche d'Ericsson a créé Erlang ils sont partis sur un modèle lightweight processes + message passing (les processus erlang sont des micro-processus tournant dans la VM erlang -- l'overhead est de 300 octets -- et ils sont ensuite mappés automatiquement par la VM sur les différents cores ou nodes). Après il y a plein d'autres trucs derrière (langage fonctionnel "bind-once", principe fondamental du "let it die" dans lequel on ne tente pas de sauver un processus qui crashe, mais on a un superviseur qui le surveille et peut relancer des processus si nécessaires, hot code loading, ...) qui mènent au fait qu'Erlang est l'un des rares langages rendant possible la création d'applications "9 nines" (99.9999999% d'uptime, soit une moyenne de 3 secondes de downtime par an). Pas de bol par contre, Erlang n'a pas été créé pour le hard real-time (il existe pour le soft real-time)
 
Après, c'est difficilement faisable en utilisant les fonctionalités de l'OS dans la mesure où les process OS sont extrèmement lourds (on peut pas dire que les threads OS soient légers non plus, mais bon...)
 
tounysbam > Honnêtement, c'est pas le genre de questions que tu devrais poser ici, tes besoins sont extrèmement spécifiques sur un OS extrèmement spécifique dans un environnement extrèmement spécifique, tu devrais essayer de trouver des forums/communautés LynxOS/embarqué pour leur poser la question et avoir une vraie réponse.

merci a tous pour vos reponses eclairées =)
Cette appli est tres portée sur la securité puisque comme vous l'avez compris embarqué et donc elle ne DOIT PAS planter.
Lynx os n est pas trop particulier dans son genre c est un os POSIX qui a la particularité d'etre certifié pour des applications liées au transport de personne  (ici un avion).
 
pour Roob :

je me suis mal exprimé je voulais dire plutot que l'appli est deja separé en taches. Maintenant il y a beaucoup de com entres ces taches (passage d'image a tres grande vitesse (300 par sec)).
 
Que pensez vous de melanger les 2 principes ? (multi thread sur les parties de l'algo qui travaillent sur les mêmes données et multiprocess entre ces differentes parties qui ne partagent que de l'info)
 
Pour ce qui est de la priorité de l'appli et bien ... il faut de la securité et des perfs (on est rikrak sur le CPU encore une fois embarqué et certif vous etes mes amis ...)
 
 

Ce qui force à établir clairement un protocole de communication, ce qui est moins sujet à erreur de programmation que de la gestion de sections critiques.