Bonjour à tous,
je n'ai jamais fait de multithreading et je cherche une référence
(anglais ou français) pour apprendre, qui remplirait notamment les
critères suivants :
- indique les design patterns qui passent bien (et ceux à éviter), les
bonnes pratiques...,
- non spécifique à une plateforme.
Adrien
Bonjour à tous,
je n'ai jamais fait de multithreading et je cherche une référence
(anglais ou français) pour apprendre, qui remplirait notamment les
critères suivants :
- indique les design patterns qui passent bien (et ceux à éviter), les
bonnes pratiques...,
- non spécifique à une plateforme.
Adrien
Bonjour à tous,
je n'ai jamais fait de multithreading et je cherche une référence
(anglais ou français) pour apprendre, qui remplirait notamment les
critères suivants :
- indique les design patterns qui passent bien (et ceux à éviter), les
bonnes pratiques...,
- non spécifique à une plateforme.
Adrien
je n'ai jamais fait de multithreading et je cherche une référence
(anglais ou français) pour apprendre, qui remplirait notamment les
critères suivants :
je n'ai jamais fait de multithreading et je cherche une référence
(anglais ou français) pour apprendre, qui remplirait notamment les
critères suivants :
je n'ai jamais fait de multithreading et je cherche une référence
(anglais ou français) pour apprendre, qui remplirait notamment les
critères suivants :
On Thu, 17 Jan 2008 06:27:24 -0800 (PST), ALB :je n'ai jamais fait de multithreading et je cherche une référence
(anglais ou français) pour apprendre, qui remplirait notamment les
critères suivants :
"Programming with POSIX threads", David R. Butenhof.http://www.amazon.fr/P /dp/0201633922/
Il parle des threads POSIX en langage C, mais les principes de
fonctionnement sont les mêmes sous Windows et en C++.
On Thu, 17 Jan 2008 06:27:24 -0800 (PST), ALB <lebatt...@crans.org>:
je n'ai jamais fait de multithreading et je cherche une référence
(anglais ou français) pour apprendre, qui remplirait notamment les
critères suivants :
"Programming with POSIX threads", David R. Butenhof.http://www.amazon.fr/P /dp/0201633922/
Il parle des threads POSIX en langage C, mais les principes de
fonctionnement sont les mêmes sous Windows et en C++.
On Thu, 17 Jan 2008 06:27:24 -0800 (PST), ALB :je n'ai jamais fait de multithreading et je cherche une référence
(anglais ou français) pour apprendre, qui remplirait notamment les
critères suivants :
"Programming with POSIX threads", David R. Butenhof.http://www.amazon.fr/P /dp/0201633922/
Il parle des threads POSIX en langage C, mais les principes de
fonctionnement sont les mêmes sous Windows et en C++.
[...] et ne s'adresse pas à
des questions plus élevées, du genre des modèles de conception à
utiliser en C++. Il y a effectivement un trou entre lui et des
livres de conception C++, et je ne connais rien qui s'y
position.
Un livre, par exemple, qui expliquerait les
différentes façons d'organiser les threads en classes. (J'en
connais trois ou quatre, dont la plus répandue est à mon avis à
éviter.)
Ni des modèles de communication entre les threads --
comment implémenter un queue de messages, par exemple. (Dans mon
cas, par exemple, j'ai choisi d'utiser auto_ptr au niveau de
l'interface -- une fois l'objet passé à l'autre thread, le
thread émitteur n'en a plus accès.)
[...] et ne s'adresse pas à
des questions plus élevées, du genre des modèles de conception à
utiliser en C++. Il y a effectivement un trou entre lui et des
livres de conception C++, et je ne connais rien qui s'y
position.
Un livre, par exemple, qui expliquerait les
différentes façons d'organiser les threads en classes. (J'en
connais trois ou quatre, dont la plus répandue est à mon avis à
éviter.)
Ni des modèles de communication entre les threads --
comment implémenter un queue de messages, par exemple. (Dans mon
cas, par exemple, j'ai choisi d'utiser auto_ptr au niveau de
l'interface -- une fois l'objet passé à l'autre thread, le
thread émitteur n'en a plus accès.)
[...] et ne s'adresse pas à
des questions plus élevées, du genre des modèles de conception à
utiliser en C++. Il y a effectivement un trou entre lui et des
livres de conception C++, et je ne connais rien qui s'y
position.
Un livre, par exemple, qui expliquerait les
différentes façons d'organiser les threads en classes. (J'en
connais trois ou quatre, dont la plus répandue est à mon avis à
éviter.)
Ni des modèles de communication entre les threads --
comment implémenter un queue de messages, par exemple. (Dans mon
cas, par exemple, j'ai choisi d'utiser auto_ptr au niveau de
l'interface -- une fois l'objet passé à l'autre thread, le
thread émitteur n'en a plus accès.)
On 18 jan, 09:29, James Kanze wrote:[...] et ne s'adresse pas à
des questions plus élevées, du genre des modèles de conception à
utiliser en C++. Il y a effectivement un trou entre lui et des
livres de conception C++, et je ne connais rien qui s'y
position.
Dans une certaine mesure, il y a les bouquins et articles de Schmidt,
non? Ils sont très orientés patterns avec pour exemple
d'implémentation sa bibliothèque, ACE -- dont je te sais peu
partisant.
Un livre, par exemple, qui expliquerait les
différentes façons d'organiser les threads en classes. (J'en
connais trois ou quatre, dont la plus répandue est à mon avis à
éviter.)
Ta parenthèse m'interresse. Tu pourrais développer STP (un lien ou un
nom m'irait).
Ni des modèles de communication entre les threads --
comment implémenter un queue de messages, par exemple. (Dans mon
cas, par exemple, j'ai choisi d'utiser auto_ptr au niveau de
l'interface -- une fois l'objet passé à l'autre thread, le
thread émitteur n'en a plus accès.)
Mais, cela ne résout pas le cas où il faut passer le message à
plusieurs threads.
On 18 jan, 09:29, James Kanze <james.ka...@gmail.com> wrote:
[...] et ne s'adresse pas à
des questions plus élevées, du genre des modèles de conception à
utiliser en C++. Il y a effectivement un trou entre lui et des
livres de conception C++, et je ne connais rien qui s'y
position.
Dans une certaine mesure, il y a les bouquins et articles de Schmidt,
non? Ils sont très orientés patterns avec pour exemple
d'implémentation sa bibliothèque, ACE -- dont je te sais peu
partisant.
Un livre, par exemple, qui expliquerait les
différentes façons d'organiser les threads en classes. (J'en
connais trois ou quatre, dont la plus répandue est à mon avis à
éviter.)
Ta parenthèse m'interresse. Tu pourrais développer STP (un lien ou un
nom m'irait).
Ni des modèles de communication entre les threads --
comment implémenter un queue de messages, par exemple. (Dans mon
cas, par exemple, j'ai choisi d'utiser auto_ptr au niveau de
l'interface -- une fois l'objet passé à l'autre thread, le
thread émitteur n'en a plus accès.)
Mais, cela ne résout pas le cas où il faut passer le message à
plusieurs threads.
On 18 jan, 09:29, James Kanze wrote:[...] et ne s'adresse pas à
des questions plus élevées, du genre des modèles de conception à
utiliser en C++. Il y a effectivement un trou entre lui et des
livres de conception C++, et je ne connais rien qui s'y
position.
Dans une certaine mesure, il y a les bouquins et articles de Schmidt,
non? Ils sont très orientés patterns avec pour exemple
d'implémentation sa bibliothèque, ACE -- dont je te sais peu
partisant.
Un livre, par exemple, qui expliquerait les
différentes façons d'organiser les threads en classes. (J'en
connais trois ou quatre, dont la plus répandue est à mon avis à
éviter.)
Ta parenthèse m'interresse. Tu pourrais développer STP (un lien ou un
nom m'irait).
Ni des modèles de communication entre les threads --
comment implémenter un queue de messages, par exemple. (Dans mon
cas, par exemple, j'ai choisi d'utiser auto_ptr au niveau de
l'interface -- une fois l'objet passé à l'autre thread, le
thread émitteur n'en a plus accès.)
Mais, cela ne résout pas le cas où il faut passer le message à
plusieurs threads.
Mais, cela ne résout pas le cas où il faut passer le message à
plusieurs threads.
Dans ce dernier cas, est ce qu'on peut vraiment eviter d'avoir
une queue par thread, et donc il faudra bien dupliquer le message
a un moment ou un autre ?
Mais, cela ne résout pas le cas où il faut passer le message à
plusieurs threads.
Dans ce dernier cas, est ce qu'on peut vraiment eviter d'avoir
une queue par thread, et donc il faudra bien dupliquer le message
a un moment ou un autre ?
Mais, cela ne résout pas le cas où il faut passer le message à
plusieurs threads.
Dans ce dernier cas, est ce qu'on peut vraiment eviter d'avoir
une queue par thread, et donc il faudra bien dupliquer le message
a un moment ou un autre ?
On 18 jan, 09:29, James Kanze wrote:[...] et ne s'adresse pas à
des questions plus élevées, du genre des modèles de conception à
utiliser en C++. Il y a effectivement un trou entre lui et des
livres de conception C++, et je ne connais rien qui s'y
position.
Dans une certaine mesure, il y a les bouquins et articles de Schmidt,
non? Ils sont très orientés patterns avec pour exemple
d'implémentation sa bibliothèque, ACE -- dont je te sais peu
partisant.
Un livre, par exemple, qui expliquerait les
différentes façons d'organiser les threads en classes. (J'en
connais trois ou quatre, dont la plus répandue est à mon avis à
éviter.)
Ta parenthèse m'interresse. Tu pourrais développer STP (un lien ou un
nom m'irait).
Ni des modèles de communication entre les threads --
comment implémenter un queue de messages, par exemple. (Dans mon
cas, par exemple, j'ai choisi d'utiser auto_ptr au niveau de
l'interface -- une fois l'objet passé à l'autre thread, le
thread émitteur n'en a plus accès.)
Mais, cela ne résout pas le cas où il faut passer le message à
plusieurs threads.
On 18 jan, 09:29, James Kanze <james.ka...@gmail.com> wrote:
[...] et ne s'adresse pas à
des questions plus élevées, du genre des modèles de conception à
utiliser en C++. Il y a effectivement un trou entre lui et des
livres de conception C++, et je ne connais rien qui s'y
position.
Dans une certaine mesure, il y a les bouquins et articles de Schmidt,
non? Ils sont très orientés patterns avec pour exemple
d'implémentation sa bibliothèque, ACE -- dont je te sais peu
partisant.
Un livre, par exemple, qui expliquerait les
différentes façons d'organiser les threads en classes. (J'en
connais trois ou quatre, dont la plus répandue est à mon avis à
éviter.)
Ta parenthèse m'interresse. Tu pourrais développer STP (un lien ou un
nom m'irait).
Ni des modèles de communication entre les threads --
comment implémenter un queue de messages, par exemple. (Dans mon
cas, par exemple, j'ai choisi d'utiser auto_ptr au niveau de
l'interface -- une fois l'objet passé à l'autre thread, le
thread émitteur n'en a plus accès.)
Mais, cela ne résout pas le cas où il faut passer le message à
plusieurs threads.
On 18 jan, 09:29, James Kanze wrote:[...] et ne s'adresse pas à
des questions plus élevées, du genre des modèles de conception à
utiliser en C++. Il y a effectivement un trou entre lui et des
livres de conception C++, et je ne connais rien qui s'y
position.
Dans une certaine mesure, il y a les bouquins et articles de Schmidt,
non? Ils sont très orientés patterns avec pour exemple
d'implémentation sa bibliothèque, ACE -- dont je te sais peu
partisant.
Un livre, par exemple, qui expliquerait les
différentes façons d'organiser les threads en classes. (J'en
connais trois ou quatre, dont la plus répandue est à mon avis à
éviter.)
Ta parenthèse m'interresse. Tu pourrais développer STP (un lien ou un
nom m'irait).
Ni des modèles de communication entre les threads --
comment implémenter un queue de messages, par exemple. (Dans mon
cas, par exemple, j'ai choisi d'utiser auto_ptr au niveau de
l'interface -- une fois l'objet passé à l'autre thread, le
thread émitteur n'en a plus accès.)
Mais, cela ne résout pas le cas où il faut passer le message à
plusieurs threads.
Dans mes propres utilisations, je distinque assez nettement
entre les threads détachés et ceux joignables : les threads
détachés sont lancés par une fonction (et ne correspondent pas
un un objet -- il n'y a pas de classe), mais dans l'ensemble,
l'implémentation n'est pas loin de celle de Boost. Les threads
joignable, en revanche, c'est bien une classe, dont appeler le
destructeur avant le join est une erreur grave (échec
d'assertion).
Dans mes propres utilisations, je distinque assez nettement
entre les threads détachés et ceux joignables : les threads
détachés sont lancés par une fonction (et ne correspondent pas
un un objet -- il n'y a pas de classe), mais dans l'ensemble,
l'implémentation n'est pas loin de celle de Boost. Les threads
joignable, en revanche, c'est bien une classe, dont appeler le
destructeur avant le join est une erreur grave (échec
d'assertion).
Dans mes propres utilisations, je distinque assez nettement
entre les threads détachés et ceux joignables : les threads
détachés sont lancés par une fonction (et ne correspondent pas
un un objet -- il n'y a pas de classe), mais dans l'ensemble,
l'implémentation n'est pas loin de celle de Boost. Les threads
joignable, en revanche, c'est bien une classe, dont appeler le
destructeur avant le join est une erreur grave (échec
d'assertion).
Dans mes propres utilisations, je distinque assez nettement
entre les threads détachés et ceux joignables : les threads
détachés sont lancés par une fonction (et ne correspondent pas
un un objet -- il n'y a pas de classe), mais dans l'ensemble,
l'implémentation n'est pas loin de celle de Boost. Les threads
joignable, en revanche, c'est bien une classe, dont appeler le
destructeur avant le join est une erreur grave (échec
d'assertion).
J'ai pour ma part tendance à distinguer entre deux catégories d'usage
multithread :
- Les threads pour aller plus vite,
- Les threads pour faire plus de choses en même temps.
Typiquement les threads pour aller plus vite, qui dépendent
d'une architecture multi-coeurs, me semble bien modélisés par
les futures (que je n'ai pas encore eu l'occasion d'utiliser),
des boucles qui s'auto parallèlisent, voir des appels de
fonction dont on ne sait même pas s'ils sont multithread ou
pas.
Les threads pour faire plus en même temps me semblent déjà bien plus
structurant au niveau du programme, font souvent tourner une boucle dans
leur fonction principale, avec ou sans timer,...
Je me demande dans quelle mesure cette classification est compatible
avec la classification joignable/détaché que tu proposes.
Dans mes propres utilisations, je distinque assez nettement
entre les threads détachés et ceux joignables : les threads
détachés sont lancés par une fonction (et ne correspondent pas
un un objet -- il n'y a pas de classe), mais dans l'ensemble,
l'implémentation n'est pas loin de celle de Boost. Les threads
joignable, en revanche, c'est bien une classe, dont appeler le
destructeur avant le join est une erreur grave (échec
d'assertion).
J'ai pour ma part tendance à distinguer entre deux catégories d'usage
multithread :
- Les threads pour aller plus vite,
- Les threads pour faire plus de choses en même temps.
Typiquement les threads pour aller plus vite, qui dépendent
d'une architecture multi-coeurs, me semble bien modélisés par
les futures (que je n'ai pas encore eu l'occasion d'utiliser),
des boucles qui s'auto parallèlisent, voir des appels de
fonction dont on ne sait même pas s'ils sont multithread ou
pas.
Les threads pour faire plus en même temps me semblent déjà bien plus
structurant au niveau du programme, font souvent tourner une boucle dans
leur fonction principale, avec ou sans timer,...
Je me demande dans quelle mesure cette classification est compatible
avec la classification joignable/détaché que tu proposes.
Dans mes propres utilisations, je distinque assez nettement
entre les threads détachés et ceux joignables : les threads
détachés sont lancés par une fonction (et ne correspondent pas
un un objet -- il n'y a pas de classe), mais dans l'ensemble,
l'implémentation n'est pas loin de celle de Boost. Les threads
joignable, en revanche, c'est bien une classe, dont appeler le
destructeur avant le join est une erreur grave (échec
d'assertion).
J'ai pour ma part tendance à distinguer entre deux catégories d'usage
multithread :
- Les threads pour aller plus vite,
- Les threads pour faire plus de choses en même temps.
Typiquement les threads pour aller plus vite, qui dépendent
d'une architecture multi-coeurs, me semble bien modélisés par
les futures (que je n'ai pas encore eu l'occasion d'utiliser),
des boucles qui s'auto parallèlisent, voir des appels de
fonction dont on ne sait même pas s'ils sont multithread ou
pas.
Les threads pour faire plus en même temps me semblent déjà bien plus
structurant au niveau du programme, font souvent tourner une boucle dans
leur fonction principale, avec ou sans timer,...
Je me demande dans quelle mesure cette classification est compatible
avec la classification joignable/détaché que tu proposes.
- Les threads pour faire plus de choses en même temps.
Est-ce que tu veux dire : pour pouvoir interrompre une activité
pour en traiter quelque chose de plus importante ? Genre,
remettre à jour la graphique, bien qu'il y ait un calcul
important qui n'a pas fini.
Les threads pour faire plus en même temps me semblent déjà bien plus
structurant au niveau du programme, font souvent tourner une boucle dans
leur fonction principale, avec ou sans timer,...
Je ne suis pas sûr que je comprends.
- Les threads pour faire plus de choses en même temps.
Est-ce que tu veux dire : pour pouvoir interrompre une activité
pour en traiter quelque chose de plus importante ? Genre,
remettre à jour la graphique, bien qu'il y ait un calcul
important qui n'a pas fini.
Les threads pour faire plus en même temps me semblent déjà bien plus
structurant au niveau du programme, font souvent tourner une boucle dans
leur fonction principale, avec ou sans timer,...
Je ne suis pas sûr que je comprends.
- Les threads pour faire plus de choses en même temps.
Est-ce que tu veux dire : pour pouvoir interrompre une activité
pour en traiter quelque chose de plus importante ? Genre,
remettre à jour la graphique, bien qu'il y ait un calcul
important qui n'a pas fini.
Les threads pour faire plus en même temps me semblent déjà bien plus
structurant au niveau du programme, font souvent tourner une boucle dans
leur fonction principale, avec ou sans timer,...
Je ne suis pas sûr que je comprends.