Discussion :

[lpierard]

Bjr à tous.

Je cherche à résoudre correctement les 3 problèmes suivants :

I) Multi-ordonnancement de plusieurs tas de données, ce qui implique une gestion des données généralement basées sur des clés composées.

Réduction des temps d'accès aux données les plus souvent mises à jour.

Après une bonne dose de recherche, et de réflexion, j'envisage une solution combinant les treaps et des arbres. (binaires ou n-aires, j'hésite encore).
Quelqu'un a-t'il des recommandations à ce sujet ?

II) Modélisation technique/contexte fonctionnel :
Il s'agit d'une application passerelle gérant des entrées/sorties entre une application maitre et des grappes de périphériques. C'est à dire un super driver bi-directionel.

Aujourd'hui l'interface entre l'application et les grappes de périphériques est en USB-I2C. Le driver (dll) associé n'est pas réentrant, le protocole est unidirectionel. on peut donc envisagé une state machine.

Le hot-plug d'une racine de grappe, ou d'un périphérique à une grappe déjà existante est un objectif pertinent.

D'autres technologies comme USB-SPI, USB-CAN, TCP-IP-CAN, sont envisageables ultérieurement. Il parait probable qu'il faudra alors :
1) implémenter des state machine pour chacune des nouvelles technologies.
2) threader chacune de ces state machines.
Il y a t-il des critiques pertinentes à cette approche ?

III) L'application maître est excessivement gourmande en ressource. Pour cette raison (et par habitude de programmation), j'écarte (possiblement à tort) le C++ et je retiens le C. L'approche objet faciliterait peut-être l'intégration, la co-existence et la coopération des technologies envisagées, sans oublier la vitesse de développement. Je crains cependant un surcoût temps d'exécution/occupation mémoire. Vous connaissez le périmètre fonctionnel.
S'il y a delta de performance entre C/C++, de quel ordre pourrait t-il être 10% ? 20% ? Question idiote ? (dans ce cas, désolé; mon intention n'est pas de troller, j'ai d'autre chose à faire ).

Merci de leur attention à tous ceux qui ont lu ce message jusqu'au bout.
Amicalement

[souviron34]

• Primo, avoir un langage plus généraliste faciliterais la compréension et donc l'aide
• Secondo, moi, pour une architecture maître->grappe, je favoriserais des serveurs..., chaque serveur pouvant être maître...