Je ne sais pas si je suis sur le bon forum, mais je n'en trouve pas
de plus adapté. Toute redirection sera donc acceptée ;-)
Ma question porte sur la libboost qui est une bibliothèque écrite en
C++. J'utilise des fonctions de la boost_graph dans un bout de code
écrit en C et Fortran (toutes versions). Le code en question tourne en
environnement POSIX sur machines parallèles et la parallélisation
est faite actuellement à grands coups de fork(). Le fork() n'est pas
pénalisant parce que chaque calcul prend quelques minutes.
Problème : l'occupation mémoire. Chaque processus consommant un peu
plus d'un gigaoctet et la machine en question ayant 32 processeurs, il faut
soit que je limite le nombre de processus, soit que j'augmente la taille
mémoire. Vu le prix de la mémoire de la bête, je préfère trouver une
solution médiane... D'où l'idée d'utiliser des threads (la majeure
partie de la mémoire est utilisée par des données qui ne changent pas
d'un processus à un autre).
Pour raisons de portabilité, j'utilise gcc/gfortran/g++ sur toutes
mes architectures cibles (essentiellement du Solaris et du Linux).
Je n'arrive pas à trouver d'information pertinente (des infos, j'en
ai trouvé, mais pas pertinentes, ou alors, je n'ai pas tout compris, ce
qui est fort possible...) sur le paramètre BOOST_HAS_THREADS.
D'après ce que j'ai compris, cette valeur est donnée par le couple
architecture et compilateur.
Sachant que j'utilise depuis pas mal de temps les threads sur ces
mêmes architectures sans problème, je ne vois pas trop pourquoi cette
valeur n'est pas définie.
Question : les fonctions de boost/graph sont-elles thread safe
malgré cette variable ? Je n'utilise que astar_search. Autrement dit,
puis-je appeler sans vergogne astar_search depuis plusieurs threads (sur
le même graphe bien entendu) mais avec des sommets de départ et
d'arrivée différents ?
Merci de vos lumières,
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Est-ce que tu as regardé les classe subgraph et filtered_graph ? Ca te permet de creer des "vues" sur un graphe existant, sans copier le contenu (donc tu n'as qu'une seule representation physique du graphe, et en particulier des proprietes internes).
Merci de vous intéresser au problème, mais je n'ai pas besoin de ce genre de fonctions. Je ne m'intéresse qu'aux voies carrossables quelles que soient ces voies. Le but est d'aller le plus vite possible d'un point à un autre sur l'ensemble d'un pays. Comme ce calcul d'itinéraire n'est qu'un pouillème du calcul final, je m'attache déjà à optimiser le reste du calcul avant de rentrer dans de telles considérations.
Je me doutais bien que ca allait etre inutile, ne connaissant pas le probleme ni la methode.
Au passage, j'ai essayé de ressortir le graphe de la fonction astar_search sans succès (g++ me renvoie une erreur au niveau de l'appel de la fonction C++ depuis mes routines C). J'ai donc gardé mon graphe statique en collant au niveau de l'appel, dans ma routine C, un mutex pour éviter des problèmes d'initialisations concurrentes.
C'est le minimum syndical pour esperer que ca marche.
JKB a écrit :
Est-ce que tu as regardé les classe subgraph et filtered_graph ? Ca te
permet de creer des "vues" sur un graphe existant, sans copier le
contenu (donc tu n'as qu'une seule representation physique du graphe,
et en particulier des proprietes internes).
Merci de vous intéresser au problème, mais je n'ai pas besoin de ce
genre de fonctions. Je ne m'intéresse qu'aux voies carrossables quelles
que soient ces voies. Le but est d'aller le plus vite possible d'un
point à un autre sur l'ensemble d'un pays. Comme ce calcul d'itinéraire
n'est qu'un pouillème du calcul final, je m'attache déjà à optimiser le
reste du calcul avant de rentrer dans de telles considérations.
Je me doutais bien que ca allait etre inutile, ne connaissant pas
le probleme ni la methode.
Au passage, j'ai essayé de ressortir le graphe de la fonction
astar_search sans succès (g++ me renvoie une erreur au niveau de l'appel
de la fonction C++ depuis mes routines C). J'ai donc gardé mon graphe
statique en collant au niveau de l'appel, dans ma routine C, un mutex
pour éviter des problèmes d'initialisations concurrentes.
C'est le minimum syndical pour esperer que ca marche.
Est-ce que tu as regardé les classe subgraph et filtered_graph ? Ca te permet de creer des "vues" sur un graphe existant, sans copier le contenu (donc tu n'as qu'une seule representation physique du graphe, et en particulier des proprietes internes).
Merci de vous intéresser au problème, mais je n'ai pas besoin de ce genre de fonctions. Je ne m'intéresse qu'aux voies carrossables quelles que soient ces voies. Le but est d'aller le plus vite possible d'un point à un autre sur l'ensemble d'un pays. Comme ce calcul d'itinéraire n'est qu'un pouillème du calcul final, je m'attache déjà à optimiser le reste du calcul avant de rentrer dans de telles considérations.
Je me doutais bien que ca allait etre inutile, ne connaissant pas le probleme ni la methode.
Au passage, j'ai essayé de ressortir le graphe de la fonction astar_search sans succès (g++ me renvoie une erreur au niveau de l'appel de la fonction C++ depuis mes routines C). J'ai donc gardé mon graphe statique en collant au niveau de l'appel, dans ma routine C, un mutex pour éviter des problèmes d'initialisations concurrentes.
C'est le minimum syndical pour esperer que ca marche.
JKB
Le 03-12-2008, ? propos de Re: Threads et boost, Michel Decima ?crivait dans fr.comp.lang.c++ :
JKB a écrit :
Est-ce que tu as regardé les classe subgraph et filtered_graph ? Ca te permet de creer des "vues" sur un graphe existant, sans copier le contenu (donc tu n'as qu'une seule representation physique du graphe, et en particulier des proprietes internes).
Merci de vous intéresser au problème, mais je n'ai pas besoin de ce genre de fonctions. Je ne m'intéresse qu'aux voies carrossables quelles que soient ces voies. Le but est d'aller le plus vite possible d'un point à un autre sur l'ensemble d'un pays. Comme ce calcul d'itinéraire n'est qu'un pouillème du calcul final, je m'attache déjà à optimiser le reste du calcul avant de rentrer dans de telles considérations.
Je me doutais bien que ca allait etre inutile, ne connaissant pas le probleme ni la methode.
Au passage, j'ai essayé de ressortir le graphe de la fonction astar_search sans succès (g++ me renvoie une erreur au niveau de l'appel de la fonction C++ depuis mes routines C). J'ai donc gardé mon graphe statique en collant au niveau de l'appel, dans ma routine C, un mutex pour éviter des problèmes d'initialisations concurrentes.
C'est le minimum syndical pour esperer que ca marche.
Alors pour ceux qui se posent la question ;-) astar_search() est thread-safe si le grahe est statique.
Cordialement,
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 03-12-2008, ? propos de
Re: Threads et boost,
Michel Decima ?crivait dans fr.comp.lang.c++ :
JKB a écrit :
Est-ce que tu as regardé les classe subgraph et filtered_graph ? Ca te
permet de creer des "vues" sur un graphe existant, sans copier le
contenu (donc tu n'as qu'une seule representation physique du graphe,
et en particulier des proprietes internes).
Merci de vous intéresser au problème, mais je n'ai pas besoin de ce
genre de fonctions. Je ne m'intéresse qu'aux voies carrossables quelles
que soient ces voies. Le but est d'aller le plus vite possible d'un
point à un autre sur l'ensemble d'un pays. Comme ce calcul d'itinéraire
n'est qu'un pouillème du calcul final, je m'attache déjà à optimiser le
reste du calcul avant de rentrer dans de telles considérations.
Je me doutais bien que ca allait etre inutile, ne connaissant pas
le probleme ni la methode.
Au passage, j'ai essayé de ressortir le graphe de la fonction
astar_search sans succès (g++ me renvoie une erreur au niveau de l'appel
de la fonction C++ depuis mes routines C). J'ai donc gardé mon graphe
statique en collant au niveau de l'appel, dans ma routine C, un mutex
pour éviter des problèmes d'initialisations concurrentes.
C'est le minimum syndical pour esperer que ca marche.
Alors pour ceux qui se posent la question ;-) astar_search() est
thread-safe si le grahe est statique.
Cordialement,
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 03-12-2008, ? propos de Re: Threads et boost, Michel Decima ?crivait dans fr.comp.lang.c++ :
JKB a écrit :
Est-ce que tu as regardé les classe subgraph et filtered_graph ? Ca te permet de creer des "vues" sur un graphe existant, sans copier le contenu (donc tu n'as qu'une seule representation physique du graphe, et en particulier des proprietes internes).
Merci de vous intéresser au problème, mais je n'ai pas besoin de ce genre de fonctions. Je ne m'intéresse qu'aux voies carrossables quelles que soient ces voies. Le but est d'aller le plus vite possible d'un point à un autre sur l'ensemble d'un pays. Comme ce calcul d'itinéraire n'est qu'un pouillème du calcul final, je m'attache déjà à optimiser le reste du calcul avant de rentrer dans de telles considérations.
Je me doutais bien que ca allait etre inutile, ne connaissant pas le probleme ni la methode.
Au passage, j'ai essayé de ressortir le graphe de la fonction astar_search sans succès (g++ me renvoie une erreur au niveau de l'appel de la fonction C++ depuis mes routines C). J'ai donc gardé mon graphe statique en collant au niveau de l'appel, dans ma routine C, un mutex pour éviter des problèmes d'initialisations concurrentes.
C'est le minimum syndical pour esperer que ca marche.
Alors pour ceux qui se posent la question ;-) astar_search() est thread-safe si le grahe est statique.
Cordialement,
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
