Comment dois-je gérer la mémoire dans mon application intégrée essentielle de mission?
J'ai trouvé des articles avec Google, mais je n'ai pas pu identifier un guide pratique vraiment utile.
Le Les réponses peuvent être constituées de la réponse régulière, de la référence à une ressource ou de la référence au bon système intégré d'OpenSource, par exemple.
Clarification: Le problème ici n'est pas si une gestion de la mémoire est disponible pour le système embarqué. Mais quel est un bon design pour un système intégré, maximiser la fiabilité.
Je ne comprends pas pourquoi prendre une piscine tampon statique et la gêne de manière dynamique, est différente de l'allocation dynamique de la mémoire. do-178b interdit les allocations de mémoire dynamique, mais comment allez-vous gérer la mémoire alors? Préallocate tout à l'avance et envoyer un pointeur à chaque fonction qui a besoin d'une allocation? Allouer sur la pile? Utilisez un allocateur statique global (mais il est très similaire à l'allocation dynamique)?
7 Réponses :
Tout allouer de la pile est couramment fait dans des systèmes embarqués ou ailleurs où la possibilité d'une échéance d'une répartition est inacceptable. Je ne sais pas ce que le DO-178B est, mais si le problème est que MALLOC n'est pas disponible sur votre plate-forme, vous pouvez également la mettre en œuvre vous-même (mise en œuvre de votre propre tas), mais cela peut toujours conduire à une allocation d'allocation lorsque vous exécutez hors de l'espace, bien sûr.
Le DO-178B est une norme pour les logiciels avioniques. Le problème n'est pas la disponibilité de MALLOC, mais une bonne conception logicielle critique de mission.
Les systèmes critiques de la mission en temps réel, à long terme, ne doivent pas allouer de manière dynamique et la mémoire libre du tas. Si vous besoin et ne pouvez pas concevoir autour de lui pour écrire votre propre schéma de gestion de pool alloué et fixe. Oui, alloué fixe à l'avance chaque fois que possible. Tout le reste demande des problèmes éventuels.
Il n'y a aucun moyen d'être sûr à 100%.
Vous pouvez regarder des exemples d'allocateurs de mémoire Freertos. Ceux-ci utilisent une piscine statique, si je ne me trompe pas.
Mais la mémoire dynamique allouée à l'aide de pools statiques acceptables dans les applications critiques?
Oui et non. Tout comme dans le cas d'une allocation dynamique, il y a une chance de manquer de piscine. Vous devez vous demander si vous pouvez tolérer cela. En dehors de cela, il existe un tas de problèmes liés à la mise en œuvre de l'allocator personnalisée (fragmentation, optimisation, yada yada)
Vous pourriez trouver Cette question intéressante également, la répartition dynamique est souvent Interdit dans les réglages trempés de l'espace (en fait, la mémoire principale est toujours utile là-bas).
Typiquement, lorsque MALLOC () n'est pas disponible, je viens d'utiliser la pile. Comme TRONIC dit, toute la raison derrière MALLOC () est que cela peut échouer. Si vous utilisez un pool statique global, il est concevable que votre mise en œuvre MALLOC () interne puisse être faillite.
C'est vraiment, vraiment, dépend vraiment de la tâche à portée de main et de ce que la planche va être exposée à.
Je ne comprends vraiment vraiment vraiment pas la manière dont votre MALLOC mis en œuvre en interne peut être défini sur l'échec. Si vous essayez vraiment de calculer quelque chose (disons, numérotez le chemin de votre robot devriez prendre pour atteindre sa destination) et vous avez une entrée trop longue, vous pourriez utiliser de l'espace pour stocker toutes les étapes à prendre. Vous devez prendre en charge cela, que vous utilisiez une allocation de mémoire dynamique ou statique.
@Elazar Leibovich: Si vous avez une piscine allouée statiquement allouée, vous SAVOIR Vous avez la mémoire pour accomplir la tâche, compte tenu des limitations de conception de tout ce que vous travaillez. Un robot qui a dû traverser un continent suggère une configuration matérielle entièrement différente d'une autre que celle qui devait marcher d'une pièce à l'autre. De plus, je ne voudrais probablement pas mettre en place un MALLOC interne () sur une carte horaire RAD. Votre question est bonne, mais plutôt générale, ces problèmes tendent à être extrêmement spécifiques à la tâche.
Assez juste, vous devez avoir suffisamment de mémoire pour effectuer la tâche spécifique que votre matériel intégré est tenu de faire. Mais parfois, vous vous trouvez en train d'écrire des morceaux de code généraux, ce qui pourrait être pertinent pour un autre projet intégré. Par exemple, vous mettez en œuvre DIJKSTRA. Votre objectif général Dijkstra peut avoir besoin d'allouer de la mémoire et devrait échouer de manière graine s'il n'a pas assez de mémoire. Bien sûr, le système ne manquerait jamais, car il n'utiliserait pas Dijkstra s'il n'aurait pas assez de mémoire pour cela, mais Dijkstra elle-même pourrait échouer.
Disclaimer: Je n'ai pas travaillé spécifiquement avec DO-178B, mais j'ai écrit des logiciels pour des systèmes certifiés.
sur les systèmes certifiés pour lesquels j'ai été développeur, ...
Cela nous a laissé avec les options suivantes ...
Notre société a trouvé que les piscines de structures puis obtenez / relâchez-le de / de retour dans la piscine étaient les plus utiles. Nous avons pu rester au modèle et garder les choses déterministes avec des problèmes minimaux.
espère que cela aide.
Mais ne gêne-t-il pas / libérer des pools de mémoire équivalents à la mise en œuvre de l'allocation dynamique vous-même?
Non, ils sont similaires mais pas équivalents. L'allocation dynamique à l'aide de MALLOC () et libre () conduit à la fragmentation de la mémoire et la possibilité d'un échec MALLOC () en raison de la fragmentation. Les systèmes certifiés l'évitent ainsi parce que c'est un pita royal de certifier. Les articles de la piscine peuvent être dispersés, mais l'article obtient la routine est garanti pour réussir à condition qu'il existe des articles inutilisés. Peu importe la dispersion des articles dans la piscine.
Je ne suis en aucun cas un expert du système d'exploitation, alors corrigez-moi si je me trompe, mais en supposant qu'il n'y a qu'un seul fil à l'aide de Malloc () et gratuit (), il n'y aura pas de fragmentation si vous êtes en effet libre Tout ce que vous avez maloclé? Et au cas où vous ne le feriez pas, bien sûr, courir dans des problèmes de toute façon ... de toute façon, le fait que deux threads utilisent le même pool est vraiment un gros problème avec la gestion de la mémoire traditionnelle.
L'ordre dans lequel la mémoire est libérée et quels blocs de mémoire alloué ont été libérés affecteront le degré de fragmentation. Si vous MALLOC () 1 KB, 2 Ko et 4 Ko, ces blocs ne sont pas garantis pour être contigus. S'ils se trouvaient, libérant les 2 ko, mais pas les autres introduiraient une certaine fragmentation de la mémoire. N'oubliez pas que toutes les structures allouées ne persistent pas la même durée - certaines sont transitoires.
Voici mon point. Dans un système intégré réactif, la fragmentation de la mémoire n'est possible que si vous n'avez pas libre que vos données Malloc'd à la fin de la boucle principale du système. Si vous assurez-vous de libérer chaque masloc avant la fin de la boucle principale - vous êtes correct, quelle que soit la méthode de gestion de la mémoire que vous choisissez. D'accord?
Une approche qui est souvent utile pour certains types d'applications est un allocator Mark / Release Lifo, qui peut être mis en œuvre de manière à ce que chaque autre allocation soit annulée dans l'ordre inverse de l'allocation (piégeage si cela n'est pas terminé) , ou implémenté de sorte que la libération de tout ce qui libère automatiquement tout alloué par la suite. Ce dernier modèle peut être mis en œuvre avec zéro coût par allocation et aucun motif n'a aucun risque de fragmentation. Soit devrait être en sécurité avec une configuration du compilateur qui convient à la programmation de systèmes, mais ...
... Soit peut être miné par un optimiseur excessivement "intelligent".
Comme quelqu'un qui a traité des systèmes embarqués, mais pas à une telle rigueur jusqu'à présent (j'ai lu DO-178B, cependant):
Vraiment, cependant, je pense que vos réponses se trouvent pour rejoindre http://www.do178site.com/ < / a>
J'ai travaillé dans un environnement DO-178B (systèmes d'avion). Ce que j'ai compris, c'est que la principale raison de ne pas permettre l'attribution dynamique est principalement la certification. La certification est effectuée par des tests (unitaire, une couverture, une intégration, ...). Avec ces tests, vous devez prouver que vous le comportement de votre programme est 100% prévisible, presque au point que l'empreinte mémoire de votre processus est la même d'une exécution à l'autre. Comme l'allocation dynamique est effectuée sur le tas (et peut échouer), vous ne pouvez pas prouver que (j'imagine que cela devrait être possible si vous maîtrisez tous les outils du matériel à n'importe quel code écrit, mais ...). Vous n'avez pas ce problème avec une allocation statique. C'est aussi pourquoi C ++ n'a pas été utilisé à ce moment dans de tels environnements. (Il était il y a environ 15 ans, cela aurait pu changer ...)
Pratiquement, vous devez écrire beaucoup de piscines de structure et de fonctions d'allocation garantissant que vous avez quelque chose de déterministe. Vous pouvez imaginer beaucoup de solutions. La clé est que vous devez prouver (avec des tonnes de tests) un niveau élevé de comportement déterministe. Il est plus facile de prouver que vos travaux de développement fabriqués à la main déterminent déterminemment que pour prouver que Linux + GCC est déterministe dans l'allocation de la mémoire.
juste mes 2 cents. Il y a longtemps, les choses auraient pu changer, mais concernant la certification comme DO-178B, le but est de prouver que votre application fonctionnera de la même manière dans n'importe quel contexte.