Si cela a de l'importance, mon environnement de
développement est le compilateur Intel C++ avec
parallélisation avec OpenMP sur Itanium 2. La biblio est
donc celle de dinkumware, dont la documentation précise
qu'elle est thread-safe
(http://www.dinkumware.com/libcpp.html) mais sans donner
plus de garantie.
Si cela a de l'importance, mon environnement de
développement est le compilateur Intel C++ avec
parallélisation avec OpenMP sur Itanium 2. La biblio est
donc celle de dinkumware, dont la documentation précise
qu'elle est thread-safe
(http://www.dinkumware.com/libcpp.html) mais sans donner
plus de garantie.
Si cela a de l'importance, mon environnement de
développement est le compilateur Intel C++ avec
parallélisation avec OpenMP sur Itanium 2. La biblio est
donc celle de dinkumware, dont la documentation précise
qu'elle est thread-safe
(http://www.dinkumware.com/libcpp.html) mais sans donner
plus de garantie.
Je débute avec la programmation multi-threaded. La preuve, j'ignore même
comment on dit « multi-threaded » ou « thread-safety » en français.
J'aimerais savoir quelles sont les garanties que les conteneurs de la
bibliothèque standard se comportent de la manière attendue dans un
programme multi-threaded. Je suis bien conscient que ce n'est
certainement pas précisé dans la norme du C++ mais en pratique, qu'en
est-il des compilateurs et bibliothèques actuelles ?
Pour donner un exemple, si je fais des insertions, lectures et
suppressions dans une std::map partagé pas plusieurs threads, est-il
nécessaire de placer des locks autour de ces opérations ?
Bonjour à tous.
Comment ça va sur fclc++ depuis les années ?
Je débute avec la programmation multi-threaded. La preuve, j'ignore même
comment on dit « multi-threaded » ou « thread-safety » en français.
J'aimerais savoir quelles sont les garanties que les conteneurs de la
bibliothèque standard se comportent de la manière attendue dans un
programme multi-threaded. Je suis bien conscient que ce n'est
certainement pas précisé dans la norme du C++ mais en pratique, qu'en
est-il des compilateurs et bibliothèques actuelles ?
Pour donner un exemple, si je fais des insertions, lectures et
suppressions dans une std::map partagé pas plusieurs threads, est-il
nécessaire de placer des locks autour de ces opérations ?
Si cela a de l'importance, mon environnement de développement est le
compilateur Intel C++ avec parallélisation avec OpenMP sur Itanium 2. La
biblio est donc celle de dinkumware, dont la documentation précise
qu'elle est thread-safe (http://www.dinkumware.com/libcpp.html) mais
sans donner plus de garantie.
Merci.
Je débute avec la programmation multi-threaded. La preuve, j'ignore même
comment on dit « multi-threaded » ou « thread-safety » en français.
J'aimerais savoir quelles sont les garanties que les conteneurs de la
bibliothèque standard se comportent de la manière attendue dans un
programme multi-threaded. Je suis bien conscient que ce n'est
certainement pas précisé dans la norme du C++ mais en pratique, qu'en
est-il des compilateurs et bibliothèques actuelles ?
Pour donner un exemple, si je fais des insertions, lectures et
suppressions dans une std::map partagé pas plusieurs threads, est-il
nécessaire de placer des locks autour de ces opérations ?
Bonjour à tous.
Comment ça va sur fclc++ depuis les années ?
Je débute avec la programmation multi-threaded. La preuve, j'ignore même
comment on dit « multi-threaded » ou « thread-safety » en français.
J'aimerais savoir quelles sont les garanties que les conteneurs de la
bibliothèque standard se comportent de la manière attendue dans un
programme multi-threaded. Je suis bien conscient que ce n'est
certainement pas précisé dans la norme du C++ mais en pratique, qu'en
est-il des compilateurs et bibliothèques actuelles ?
Pour donner un exemple, si je fais des insertions, lectures et
suppressions dans une std::map partagé pas plusieurs threads, est-il
nécessaire de placer des locks autour de ces opérations ?
Si cela a de l'importance, mon environnement de développement est le
compilateur Intel C++ avec parallélisation avec OpenMP sur Itanium 2. La
biblio est donc celle de dinkumware, dont la documentation précise
qu'elle est thread-safe (http://www.dinkumware.com/libcpp.html) mais
sans donner plus de garantie.
Merci.
Je débute avec la programmation multi-threaded. La preuve, j'ignore même
comment on dit « multi-threaded » ou « thread-safety » en français.
J'aimerais savoir quelles sont les garanties que les conteneurs de la
bibliothèque standard se comportent de la manière attendue dans un
programme multi-threaded. Je suis bien conscient que ce n'est
certainement pas précisé dans la norme du C++ mais en pratique, qu'en
est-il des compilateurs et bibliothèques actuelles ?
Pour donner un exemple, si je fais des insertions, lectures et
suppressions dans une std::map partagé pas plusieurs threads, est-il
nécessaire de placer des locks autour de ces opérations ?
Bonjour à tous.
Comment ça va sur fclc++ depuis les années ?
Je débute avec la programmation multi-threaded. La preuve, j'ignore même
comment on dit « multi-threaded » ou « thread-safety » en français.
J'aimerais savoir quelles sont les garanties que les conteneurs de la
bibliothèque standard se comportent de la manière attendue dans un
programme multi-threaded. Je suis bien conscient que ce n'est
certainement pas précisé dans la norme du C++ mais en pratique, qu'en
est-il des compilateurs et bibliothèques actuelles ?
Pour donner un exemple, si je fais des insertions, lectures et
suppressions dans une std::map partagé pas plusieurs threads, est-il
nécessaire de placer des locks autour de ces opérations ?
Si cela a de l'importance, mon environnement de développement est le
compilateur Intel C++ avec parallélisation avec OpenMP sur Itanium 2. La
biblio est donc celle de dinkumware, dont la documentation précise
qu'elle est thread-safe (http://www.dinkumware.com/libcpp.html) mais
sans donner plus de garantie.
Merci.
Marc Duflot writes:Si cela a de l'importance, mon environnement de
développement est le compilateur Intel C++ avec
parallélisation avec OpenMP sur Itanium 2. La biblio est
donc celle de dinkumware, dont la documentation précise
qu'elle est thread-safe
(http://www.dinkumware.com/libcpp.html) mais sans donner
plus de garantie.
Seuls eux peuvent te renseigner. Il y a differents niveaux:
- au niveau le plus bas, rien n'est garanti; meme pas que
l'acces a des objets differents, que des appels à des
fonctions sans rapports dans des threads différentes se
se comportent sainement;
- à un niveau moyen, les exemples ci-dessus fonctionnent
(pour autant qu'ils soient sensés (appeler strtok dans
2 threads pose des problèmes de pertinence de
l'interface dans ce contexte), deux lectures
simultanées fonctionneraient aussi (mais pas une lecture et
une écriture)
- au niveau le plus elevé, on peut modifier un même objet
dans deux threads simultanément.
Naturellement, il y a en fait un tas de niveaux
intermédiaires... À mon avis, seul le niveau moyen tel
qu'esquissé est intéressant pour une bibliothèque standard;
tout protéger a un coût trop important sans avantages
pratiques: ce qui importe bien souvent c'est de maintenire
des invariants faisant intervenir plusieurs objets, ce qui
n'est jamais possible automatiquement.
Marc Duflot <marc.duflot@gmail.com> writes:
Si cela a de l'importance, mon environnement de
développement est le compilateur Intel C++ avec
parallélisation avec OpenMP sur Itanium 2. La biblio est
donc celle de dinkumware, dont la documentation précise
qu'elle est thread-safe
(http://www.dinkumware.com/libcpp.html) mais sans donner
plus de garantie.
Seuls eux peuvent te renseigner. Il y a differents niveaux:
- au niveau le plus bas, rien n'est garanti; meme pas que
l'acces a des objets differents, que des appels à des
fonctions sans rapports dans des threads différentes se
se comportent sainement;
- à un niveau moyen, les exemples ci-dessus fonctionnent
(pour autant qu'ils soient sensés (appeler strtok dans
2 threads pose des problèmes de pertinence de
l'interface dans ce contexte), deux lectures
simultanées fonctionneraient aussi (mais pas une lecture et
une écriture)
- au niveau le plus elevé, on peut modifier un même objet
dans deux threads simultanément.
Naturellement, il y a en fait un tas de niveaux
intermédiaires... À mon avis, seul le niveau moyen tel
qu'esquissé est intéressant pour une bibliothèque standard;
tout protéger a un coût trop important sans avantages
pratiques: ce qui importe bien souvent c'est de maintenire
des invariants faisant intervenir plusieurs objets, ce qui
n'est jamais possible automatiquement.
Marc Duflot writes:Si cela a de l'importance, mon environnement de
développement est le compilateur Intel C++ avec
parallélisation avec OpenMP sur Itanium 2. La biblio est
donc celle de dinkumware, dont la documentation précise
qu'elle est thread-safe
(http://www.dinkumware.com/libcpp.html) mais sans donner
plus de garantie.
Seuls eux peuvent te renseigner. Il y a differents niveaux:
- au niveau le plus bas, rien n'est garanti; meme pas que
l'acces a des objets differents, que des appels à des
fonctions sans rapports dans des threads différentes se
se comportent sainement;
- à un niveau moyen, les exemples ci-dessus fonctionnent
(pour autant qu'ils soient sensés (appeler strtok dans
2 threads pose des problèmes de pertinence de
l'interface dans ce contexte), deux lectures
simultanées fonctionneraient aussi (mais pas une lecture et
une écriture)
- au niveau le plus elevé, on peut modifier un même objet
dans deux threads simultanément.
Naturellement, il y a en fait un tas de niveaux
intermédiaires... À mon avis, seul le niveau moyen tel
qu'esquissé est intéressant pour une bibliothèque standard;
tout protéger a un coût trop important sans avantages
pratiques: ce qui importe bien souvent c'est de maintenire
des invariants faisant intervenir plusieurs objets, ce qui
n'est jamais possible automatiquement.
Je débute avec la programmation multi-threaded. La preuve, j'ignore même
comment on dit « multi-threaded » ou « thread-safety » en français.
J'aimerais savoir quelles sont les garanties que les
conteneurs de la bibliothèque standard se comportent de la
manière attendue dans un programme multi-threaded.
Je suis bien conscient que ce n'est certainement pas précisé
dans la norme du C++ mais en pratique, qu'en est-il des
compilateurs et bibliothèques actuelles ?
Pour donner un exemple, si je fais des insertions, lectures et
suppressions dans une std::map partagé pas plusieurs threads, est-il
nécessaire de placer des locks autour de ces opérations ?
Si cela a de l'importance, mon environnement de développement
est le compilateur Intel C++ avec parallélisation avec OpenMP
sur Itanium 2. La biblio est donc celle de dinkumware, dont la
documentation précise qu'elle est thread-safe
(http://www.dinkumware.com/libcpp.html) mais sans donner plus
de garantie.
Je débute avec la programmation multi-threaded. La preuve, j'ignore même
comment on dit « multi-threaded » ou « thread-safety » en français.
J'aimerais savoir quelles sont les garanties que les
conteneurs de la bibliothèque standard se comportent de la
manière attendue dans un programme multi-threaded.
Je suis bien conscient que ce n'est certainement pas précisé
dans la norme du C++ mais en pratique, qu'en est-il des
compilateurs et bibliothèques actuelles ?
Pour donner un exemple, si je fais des insertions, lectures et
suppressions dans une std::map partagé pas plusieurs threads, est-il
nécessaire de placer des locks autour de ces opérations ?
Si cela a de l'importance, mon environnement de développement
est le compilateur Intel C++ avec parallélisation avec OpenMP
sur Itanium 2. La biblio est donc celle de dinkumware, dont la
documentation précise qu'elle est thread-safe
(http://www.dinkumware.com/libcpp.html) mais sans donner plus
de garantie.
Je débute avec la programmation multi-threaded. La preuve, j'ignore même
comment on dit « multi-threaded » ou « thread-safety » en français.
J'aimerais savoir quelles sont les garanties que les
conteneurs de la bibliothèque standard se comportent de la
manière attendue dans un programme multi-threaded.
Je suis bien conscient que ce n'est certainement pas précisé
dans la norme du C++ mais en pratique, qu'en est-il des
compilateurs et bibliothèques actuelles ?
Pour donner un exemple, si je fais des insertions, lectures et
suppressions dans une std::map partagé pas plusieurs threads, est-il
nécessaire de placer des locks autour de ces opérations ?
Si cela a de l'importance, mon environnement de développement
est le compilateur Intel C++ avec parallélisation avec OpenMP
sur Itanium 2. La biblio est donc celle de dinkumware, dont la
documentation précise qu'elle est thread-safe
(http://www.dinkumware.com/libcpp.html) mais sans donner plus
de garantie.
Je débute avec la programmation multi-threaded. La preuve,
j'ignore même comment on dit « multi-threaded » ou
« thread-safety » en français.
programmation multi-threaded --> programmation parallèle
peut-être ?
thread-safety --> sûreté par rapport au threads ou plus
exactement sûreté par rapport aux flots d'exécution légèrs. Je
suis preneur d'une meilleure traduction.
J'aimerais savoir quelles sont les garanties que les
conteneurs de la bibliothèque standard se comportent de la
manière attendue dans un programme multi-threaded. Je suis
bien conscient que ce n'est certainement pas précisé dans la
norme du C++ mais en pratique, qu'en est-il des compilateurs
et bibliothèques actuelles ? Pour donner un exemple, si je
fais des insertions, lectures et suppressions dans une
std::map partagé pas plusieurs threads, est-il nécessaire de
placer des locks autour de ces opérations ?
En lecture c'est "thread safe" mais en écriture il y a des
précautions à prendre.
Regarde cette page pour plus de détail.
http://www.sgi.com/tech/stl/thread_safety.html
Je débute avec la programmation multi-threaded. La preuve,
j'ignore même comment on dit « multi-threaded » ou
« thread-safety » en français.
programmation multi-threaded --> programmation parallèle
peut-être ?
thread-safety --> sûreté par rapport au threads ou plus
exactement sûreté par rapport aux flots d'exécution légèrs. Je
suis preneur d'une meilleure traduction.
J'aimerais savoir quelles sont les garanties que les
conteneurs de la bibliothèque standard se comportent de la
manière attendue dans un programme multi-threaded. Je suis
bien conscient que ce n'est certainement pas précisé dans la
norme du C++ mais en pratique, qu'en est-il des compilateurs
et bibliothèques actuelles ? Pour donner un exemple, si je
fais des insertions, lectures et suppressions dans une
std::map partagé pas plusieurs threads, est-il nécessaire de
placer des locks autour de ces opérations ?
En lecture c'est "thread safe" mais en écriture il y a des
précautions à prendre.
Regarde cette page pour plus de détail.
http://www.sgi.com/tech/stl/thread_safety.html
Je débute avec la programmation multi-threaded. La preuve,
j'ignore même comment on dit « multi-threaded » ou
« thread-safety » en français.
programmation multi-threaded --> programmation parallèle
peut-être ?
thread-safety --> sûreté par rapport au threads ou plus
exactement sûreté par rapport aux flots d'exécution légèrs. Je
suis preneur d'une meilleure traduction.
J'aimerais savoir quelles sont les garanties que les
conteneurs de la bibliothèque standard se comportent de la
manière attendue dans un programme multi-threaded. Je suis
bien conscient que ce n'est certainement pas précisé dans la
norme du C++ mais en pratique, qu'en est-il des compilateurs
et bibliothèques actuelles ? Pour donner un exemple, si je
fais des insertions, lectures et suppressions dans une
std::map partagé pas plusieurs threads, est-il nécessaire de
placer des locks autour de ces opérations ?
En lecture c'est "thread safe" mais en écriture il y a des
précautions à prendre.
Regarde cette page pour plus de détail.
http://www.sgi.com/tech/stl/thread_safety.html
Marc Duflot writes:
Si cela a de l'importance, mon environnement de
développement est le compilateur Intel C++ avec
parallélisation avec OpenMP sur Itanium 2. La biblio est
donc celle de dinkumware, dont la documentation précise
qu'elle est thread-safe
(http://www.dinkumware.com/libcpp.html) mais sans donner
plus de garantie.
Seuls eux peuvent te renseigner. Il y a differents niveaux:
- au niveau le plus bas, rien n'est garanti; meme pas que
l'acces a des objets differents, que des appels à des
fonctions sans rapports dans des threads différentes se
se comportent sainement;
- à un niveau moyen, les exemples ci-dessus fonctionnent
(pour autant qu'ils soient sensés (appeler strtok dans
2 threads pose des problèmes de pertinence de
l'interface dans ce contexte), deux lectures
simultanées fonctionneraient aussi (mais pas une lecture et
une écriture)
- au niveau le plus elevé, on peut modifier un même objet
dans deux threads simultanément.
Naturellement, il y a en fait un tas de niveaux
intermédiaires... À mon avis, seul le niveau moyen tel
qu'esquissé est intéressant pour une bibliothèque standard;
tout protéger a un coût trop important sans avantages
pratiques: ce qui importe bien souvent c'est de maintenire
des invariants faisant intervenir plusieurs objets, ce qui
n'est jamais possible automatiquement.
J'ai bien aimé un article de sutter sur le sujet :
http://www.cuj.com/documents/s88/cuj0409i/
Marc Duflot <marc.duflot@gmail.com> writes:
Si cela a de l'importance, mon environnement de
développement est le compilateur Intel C++ avec
parallélisation avec OpenMP sur Itanium 2. La biblio est
donc celle de dinkumware, dont la documentation précise
qu'elle est thread-safe
(http://www.dinkumware.com/libcpp.html) mais sans donner
plus de garantie.
Seuls eux peuvent te renseigner. Il y a differents niveaux:
- au niveau le plus bas, rien n'est garanti; meme pas que
l'acces a des objets differents, que des appels à des
fonctions sans rapports dans des threads différentes se
se comportent sainement;
- à un niveau moyen, les exemples ci-dessus fonctionnent
(pour autant qu'ils soient sensés (appeler strtok dans
2 threads pose des problèmes de pertinence de
l'interface dans ce contexte), deux lectures
simultanées fonctionneraient aussi (mais pas une lecture et
une écriture)
- au niveau le plus elevé, on peut modifier un même objet
dans deux threads simultanément.
Naturellement, il y a en fait un tas de niveaux
intermédiaires... À mon avis, seul le niveau moyen tel
qu'esquissé est intéressant pour une bibliothèque standard;
tout protéger a un coût trop important sans avantages
pratiques: ce qui importe bien souvent c'est de maintenire
des invariants faisant intervenir plusieurs objets, ce qui
n'est jamais possible automatiquement.
J'ai bien aimé un article de sutter sur le sujet :
http://www.cuj.com/documents/s88/cuj0409i/
Marc Duflot writes:
Si cela a de l'importance, mon environnement de
développement est le compilateur Intel C++ avec
parallélisation avec OpenMP sur Itanium 2. La biblio est
donc celle de dinkumware, dont la documentation précise
qu'elle est thread-safe
(http://www.dinkumware.com/libcpp.html) mais sans donner
plus de garantie.
Seuls eux peuvent te renseigner. Il y a differents niveaux:
- au niveau le plus bas, rien n'est garanti; meme pas que
l'acces a des objets differents, que des appels à des
fonctions sans rapports dans des threads différentes se
se comportent sainement;
- à un niveau moyen, les exemples ci-dessus fonctionnent
(pour autant qu'ils soient sensés (appeler strtok dans
2 threads pose des problèmes de pertinence de
l'interface dans ce contexte), deux lectures
simultanées fonctionneraient aussi (mais pas une lecture et
une écriture)
- au niveau le plus elevé, on peut modifier un même objet
dans deux threads simultanément.
Naturellement, il y a en fait un tas de niveaux
intermédiaires... À mon avis, seul le niveau moyen tel
qu'esquissé est intéressant pour une bibliothèque standard;
tout protéger a un coût trop important sans avantages
pratiques: ce qui importe bien souvent c'est de maintenire
des invariants faisant intervenir plusieurs objets, ce qui
n'est jamais possible automatiquement.
J'ai bien aimé un article de sutter sur le sujet :
http://www.cuj.com/documents/s88/cuj0409i/
J'ai bien aimé un article de sutter sur le sujet :
http://www.cuj.com/documents/s88/cuj0409i/
J'ai bien aimé un article de sutter sur le sujet :
http://www.cuj.com/documents/s88/cuj0409i/
J'ai bien aimé un article de sutter sur le sujet :
http://www.cuj.com/documents/s88/cuj0409i/
James Kanze writes:
| Ça dépend. Dans la pratique, je crois que la plupart
| (exception fait de g++) donne les même garanties que pour un
| objet de base (ou un tableau de type C).
Puisque tu répètes ceci dans tout ce fil, sans que je puisse
comprendre ce que tu voulais dire, je serais heureux d'en voir
un élaboration plus claire.
James Kanze <kanze@none> writes:
| Ça dépend. Dans la pratique, je crois que la plupart
| (exception fait de g++) donne les même garanties que pour un
| objet de base (ou un tableau de type C).
Puisque tu répètes ceci dans tout ce fil, sans que je puisse
comprendre ce que tu voulais dire, je serais heureux d'en voir
un élaboration plus claire.
James Kanze writes:
| Ça dépend. Dans la pratique, je crois que la plupart
| (exception fait de g++) donne les même garanties que pour un
| objet de base (ou un tableau de type C).
Puisque tu répètes ceci dans tout ce fil, sans que je puisse
comprendre ce que tu voulais dire, je serais heureux d'en voir
un élaboration plus claire.
