2009-10-18 12 views
1

J'envisage un ensemble de 4 programmes: (PROG1, PROG2, PROG3, PROG4) interaction avec 4 fichiers (Filea, FICHB, Filec, amparo)programmes en cours d'exécution en parallèle, lecture/écriture en C

  • prog1: écrit (concatène) à filea
  • Prog2: lit le fichier A et écrit (ajoute) à FICHB
  • PROG3: lit un fichier et écrit (ajoute) à Filec
  • PROG4: lit le fichier B, et écrit (ajoute) à FileD

ou Potentiellement Prog1, pourrait également lire au démarrage, et écrire en continu pour dire FileX.

Maintenant, tous les 4 programmes seront exécutés simultanément (sur le réseau potentiellement, mais cela ne devrait pas avoir d'importance). Est-ce que ça va marcher? Dois-je configurer des signaux "Strobes" ou "Occupé" (je pourrais le faire avec say mkdir, et rmdir)?

Répondre

0

Je pense que vous avez besoin d'une sorte de vraie structure FIFO ici, également appelée tuyaux. Il y a des constructions avec ce nom sous Windows et OS'es Unix-saveur.

Un exemple sous Linux peut être trouvé here, les pipes nommés sous Windows here

1

est votre problème de synchronisation de la lecture/écriture? Les écritures sont la partie la plus problématique puisqu'elles modifient le contenu. En outre, la nature de l'écriture (append à la fin, append au début, etc) peut compliquer davantage votre situation. J'ai le sentiment que vous devrez peut-être rechercher des "verrouillages de fichiers"/mutex etc. Beaucoup dépend du système d'exploitation (-es) que vous prévoyez d'utiliser. Boost.Interprocess est un bon endroit pour commencer.

+0

Je me demandais si je pouvais le faire de manière asynchrone. sinon je vais utiliser quelque chose comme un stroboscope, est utilisé sur un port parallèle –

+0

Que faire de manière asynchrone? – dirkgently

0

Il peut être mis au travail. Vous devez considérer quel processus ouvre chaque fichier et d'où proviennent les données que Prog1 écrit.

Si chaque programme ouvre les fichiers avec lesquels il travaille, il n'y a pas de problème majeur. Le problème principal est le même que celui de 'queue -f', à savoir que chacun des processus de lecture est susceptible d'être lu par EOF, puis de faire une pause et de réessayer pour voir quand plus de données seront disponibles.

Si vous avez un processus central qui ouvre tous les fichiers, vous devez ouvrir le fichier A pour le lire deux fois afin que Prog2 et Prog3 aient un accès indépendant au fichier. Cependant, il semble plus logique pour tout processus de coordinateur de simplement dire aux enfants quels fichiers ouvrir.

Je ne vois aucun besoin de stroboscopes ou de signaux occupés. Vous n'avez pas averti de toute exigence de réponse «quasi-difficile en temps réel» ou d'autres conditions spéciales pouvant justifier une programmation spéciale.

+0

Et il n'est pas clair comment FileX pourrait modifier les choses, voire pas du tout. Je pense que ce ne serait «pas du tout» au-delà du sens que Prog1 écrit dans deux fichiers. –

Questions connexes