Applications muti-thread/fork
Le
xavier
Bonjour,
J'ai une appli qui utilise plusieurs processus shell.
Chque processus est bien entendu identique, sauf aux données qu'il doit
traiter. C'est le rendu de ces données qui pose problème si je ne veux
pas avoir mes beaux tableaux ASCII intriqués les uns dans les autres.
Ce que je fais c'est que chaque traitement écrit dans un fichier temp,
et à la fin, je demande un sémaphore exclusif (que je peux
éventuellement attendre) sur le fichier de résultats, j'y appende les
résultats de la tâche, je lache le sémaphore, et j'attends le jeu de
données suivantes. Comme ça, tous les résultats sont bien séparés.
Est-ce une méthode correcte ? Chez moi, ça tourne sans problème depuis
10 ans avec des concurrences jusqu'à 30. Mais il y aurait mieux ?
Merci,
--
XAv
In your pomp and all your glory you're a poorer man than me,
as you lick the boots of death born out of fear.
(Jethro Tull)
J'ai une appli qui utilise plusieurs processus shell.
Chque processus est bien entendu identique, sauf aux données qu'il doit
traiter. C'est le rendu de ces données qui pose problème si je ne veux
pas avoir mes beaux tableaux ASCII intriqués les uns dans les autres.
Ce que je fais c'est que chaque traitement écrit dans un fichier temp,
et à la fin, je demande un sémaphore exclusif (que je peux
éventuellement attendre) sur le fichier de résultats, j'y appende les
résultats de la tâche, je lache le sémaphore, et j'attends le jeu de
données suivantes. Comme ça, tous les résultats sont bien séparés.
Est-ce une méthode correcte ? Chez moi, ça tourne sans problème depuis
10 ans avec des concurrences jusqu'à 30. Mais il y aurait mieux ?
Merci,
--
XAv
In your pomp and all your glory you're a poorer man than me,
as you lick the boots of death born out of fear.
(Jethro Tull)
Poser une question
Ca semble bien... L'autre solution serait de faire communiquer chaque
fils avec son père, charge à ce dernier de traiter les resultats reçus
un par un, ce qui aurait l'avantage de permettre une ecrire sur stdout
(quoi que tes fils peuvent partager le meme stdout)
Seul risque à mon avis : le plantage d'un fils alors que le semaphore
est leve ==> les autres attendrons indéfiniment
Celui-là, je le gère aussi : si j'attends plus de 5 fois la durée maxi
estimée d'une éxécution normale, je force le sémaphore.
Merci,
--
XAv
In your pomp and all your glory you're a poorer man than me,
as you lick the boots of death born out of fear.
(Jethro Tull)
C'est correct en théorie. Cependant, tu devrais préciser quel type de
sémaphore tu utilises, parce que certaines API sont une calamité.
Comme c'est du script shell, j'utilise un sémaphore au niveau du FS,
lockfile(1), plus souple que lockf(1), même si son implémentation ne
garantit pas stricto sensu l'atomicité, en tout cas ça n'est pas précisé
dans la manpage.
En Perl, j'utilise plutôt POSIX::RT::Semaphore
Merci,
--
XAv
In your pomp and all your glory you're a poorer man than me,
as you lick the boots of death born out of fear.
(Jethro Tull)
C'est raisonnable. Mais tu aurais plutôt dû parler de verrou que de
sémaphore, la sémantique n'est pas exactement la même.