Discussion :

[Charlock]

Bonjour à tous !

J'aurais aimé savoir comment il était possible de transférer des données d'un programme vers un autre.

En fait, je souhaite réaliser un programme qui gére un réseau de train miniature par l'intermédiaire du port parallèle. Le PC est relié à une carte avec un PIC.
Le problème est le suivant : les données arrivent sur le port parallèle à une cadence donnée. Je pensais donc réaliser un programme synchrone avec cette cadence qui se contente d'enregistrer les données (que le PIC lit 3 par 3 et donc que le PC recoit 3 par 3) dans un tableau. Un autre programme s'occuperait de gérer les automatismes (ex: mettre un feu au rouge si tel train est passé à tel endroit) et enfin un dernier programme serait chargé d'envoyer les données à la carte (en gérant les données prioritaires par exemple, etc.).

Donc j'aurais voulu savoir comment faire communiquer ces trois programmes (écrits en C) entre eux...

J'espère avoir été clair

Merci !

Charlock

[ronan99999]

Par réseau tcp udp
Par fichier pipe etc...
Tu peux regarder autrement la MPI.
http://fr.wikipedia.org/wiki/Message_Passing_Interface

Mais peut etre faut'il que tu repenses ton programme en terme de processus légers, pourquoi trois exe différents, si ils sont sur la meme machine.

[joellel]

Sous quel système d'exploitation travailles tu?

[Médinoc]

Euh, là, on dirait que pratiquement toutes ces données sont partagées à un moment ou un autre.

Là, je te conseillerais de faire une seule application, mais multithreadée.
(Un processus, trois threads).

[Charlock]

Merci à tous !

Mais peut etre faut'il que tu repenses ton programme en terme de processus légers, pourquoi trois exe différents, si ils sont sur la meme machine.

Bah justement c'est peut être là le problème !! C'était la première solution qui m'était passée par la tête.

Sous quel système d'exploitation travailles tu?

Je sais pas encore sur quoi je vais le faire, vu qu'il faut que je me dégotte un PC de récup. Donc peut etre MS-DOS, ou Linux. Pas Windows en tout cas

Euh, là, on dirait que pratiquement toutes ces données sont partagées à un moment ou un autre.

Là, je te conseillerais de faire une seule application, mais multithreadée.
(Un processus, trois threads).

Ca sonne bien ca Je vois l'idée mais je m'y connais pas du tout dans ce domaine. Tu peux expliquer un tout petit peu plus stp ?

[Médinoc]

Thread == processus léger.

Donc, dès le début de ton programme (le main() est le thread principal), tu crées tes buffers partagés, puis tu lances deux threads supplémentaires (avec pthread_create() sous unixoïde, _beginthreadex() sous Windows), comme ça tu te retrouves avec trois threads, qui peuvent tous les trois manipuler les buffers.
--> Un thread pour chacune des trois tâches.

Pour la copie des données reçues par le premier thread, tu devras sûrement utiliser un verrou (pour empêcher le premier thread de modifier pendant que le second lit, et permettre au second de vider le buffer).
Sous unixoïde, les verrous sont des mutex (pthread_mutex_init() ou pthread_mutex_create()), sous Windows, on utilise des CRITICAL_SECTION (InitializeCriticalSection()).
Note: le verrou doit être créé en même temps que les buffers partagés, pour être passés aux threads.

[Charlock]

OK merci beaucoup !

Je dois t'avouer que ca m'a l'air très très compliqué. Mais bon en reprenant ca au calme et après de plus amples recherches sur internet, j'ai bon espoir !

[Emmanuel Delahaye]

Je sais pas encore sur quoi je vais le faire, vu qu'il faut que je me dégotte un PC de récup. Donc peut etre MS-DOS, ou Linux. Pas Windows en tout cas

Windows, c'est le Diable !

[Pragmateek]

On peut aussi utiliser les "pthread" sous Windows.

[Médinoc]

Oui, mais pas sans bibliothèque.

Emmanuel : Je crois que c'est pour une question d'accès au port parallèle : La plupart des applications hors-imprimante utilisent le port parallèle à bas niveau, chose impossible sous WinNT à moins de développer un "kernel-mode driver".

Charlock : Par contre, tu peux utiliser un windows non-NT (mais il faut désactiver toute optimisation sur le source qui effectue les accès au port).

[gnto]

Oui, mais pas sans bibliothèque.

Hum pour faire des thread il faut toujours utiliser une bibliothèque nan ?

Emmanuel : Je crois que c'est pour une question d'accès au port parallèle : La plupart des applications hors-imprimante utilisent le port parallèle à bas niveau, chose impossible sous WinNT à moins de développer un "kernel-mode driver".

Il me semble que sous NT, c'est le HAL qui bloque la connexion car il faut certains droits. Faire un driver sous windows, il faut acheter le DDK(device driver kit) nan ?

Charlock : Par contre, tu peux utiliser un windows non-NT (mais il faut désactiver toute optimisation sur le source qui effectue les accès au port).

ui, ca fonctionne

[Médinoc]

Hum pour faire des thread il faut toujours utiliser une bibliothèque nan ?

Pas sous Win32 en tout cas (à moins que tu ne considères l'API système comme une bibliothèque).

[Pragmateek]

à moins que tu ne considères l'API système comme une bibliothèque

C'est le même principe:une interface de programmation rassemblant des fonctionnalités permettant un bon niveau d'abstraction.
Sinon quelles sont les différences notables?

[Médinoc]

Pour moi, l'API système a l'avantage suprême d'être toujours présente de base sur le système en question (et dans tous les SDK pour ledit système), surtout lorsqu'il s'agit des modules indispensables ne serait-ce qe pour lancer le programme (à commencer par kernel32.dll, qui justement est contient toute l'API pour les threads). Donc, dès qu'on programme sous Win32, on a le multithreading à portée de main.
De plus, sous Win32, tout est géré "au niveau thread" : Il n'y a pas de fonction d'attente bloquant un processus entier (j'ignore si c'est ou non le cas sous Linux)

À ce sujet, j'ai une petite question au sujet des pthreads sur linux: Dans le cas où les fonctions système d'attente de Linux bloquent uniquement le thread courant et non tout le process, c'est que Linux supporte directement les threads (comme Win32) et que libpthread.a n'est qu'une interface, non?

PS: C'est dans " Thread POSIX et gestion mémoire" qu'on voit l'utilité de gérer les threads (et le reste) par des handles...