Qui pourrait me donner une jolie explication en francais de ce qu'est le
multithreading ( je prefere m'assurer de ce que je crois savoir ) et comment
s'assurer qu'une dll le gere sans problemes ou plus exactement que les
objects COM de ma dll gere correctement cela ??
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Ambassadeur Kosh
> Qui pourrait me donner une jolie explication en francais de ce qu'est le multithreading
le resumé en une phrase de 10 mots est source de confusions.
un ordinateur est un sequenceur. il execute des actions/instructions les unes apres les autres.
pour mettre en parallele deux taches, on achete deux ordinateurs.
mais si on veux faire tourner deux taches en meme temps sur un seul séquenceur, on utilise une technique qui s'appelle le multithreading.
c'est à dire que l'on charge les deux programmes (deux suites d'instructions), et qu'on execute l'instruction du 1°, puis celle du 2°, puis celle du 1°, puis....
la rapidité et la finesse du découpage donne l'illusion de simultaneité.
si les deux programmes sont independants tout va bien. les problemes commencent quand ils se partagent des resources. par exemple une liste, une entrée sortie, ou autre chose. on appelle ça la concurence. ça donne naissance (comme dans un sgbd puisque le probleme est similaire) à la notion de section critique qui a des similitudes avec les transactions.
le non dit évident dans cet affaire, c'est qu'on écrit pas du code toute les 3 lignes dans ses programmes pour donner la main à un autre processus (ça s'appelle swaper). on en écrit même pas du tout. un processus ne doit pas avoir "conscience" qu'on passe a un autre programme. c'est l'ordonanceur (le systeme) qui décide de tout ça. et dieu sait qu'il est bien avisé.
voila, c'est la base du multi-threadind.
COM est une specification et une implantation. "ça" fourni des comportements et des formalismes pour réaliser des mécanismes clients / serveurs. et ça a quelques vertus : interoperabilité entre langages, objets distants ou locaux sans pisser une ligne de code.
( je prefere m'assurer de ce que je crois savoir )
c'est louable. j'espere quand même ne pas vous avoir trop saoulé avec des évidences.
et comment s'assurer qu'une dll le gere sans problemes ou plus exactement que les objects COM de ma dll gere correctement cela ??
c'est du COM, donc ils ont obligatoirement un modele de Thread (appartment, etc). tout objet COM a les propriétés offertes par COM.
maintenant, le "correct" est une notion qui dépend d'un peu plus que d'être ou ne pas être des objets COM.
et pour savoir si c'est du COM, c'est simple, vous importer une lib COM, et vous vous faites jetter, ou alors ça vous fabrique les wrappers (classes et interfaces) et la tlb (fichier de description. c'est comme un .h de C++, mais pour le formalisme COM)
merci.
de rien, j'espere que ça va aider.
> Qui pourrait me donner une jolie explication en francais de ce qu'est le
multithreading
le resumé en une phrase de 10 mots est source de confusions.
un ordinateur est un sequenceur. il execute des actions/instructions les
unes apres les autres.
pour mettre en parallele deux taches, on achete deux ordinateurs.
mais si on veux faire tourner deux taches en meme temps sur un seul
séquenceur, on utilise une technique qui s'appelle le multithreading.
c'est à dire que l'on charge les deux programmes (deux suites
d'instructions), et qu'on execute l'instruction du 1°, puis celle du 2°,
puis celle du 1°, puis....
la rapidité et la finesse du découpage donne l'illusion de simultaneité.
si les deux programmes sont independants tout va bien. les problemes
commencent quand ils se partagent des resources. par exemple une liste, une
entrée sortie, ou autre chose. on appelle ça la concurence. ça donne
naissance (comme dans un sgbd puisque le probleme est similaire) à la notion
de section critique qui a des similitudes avec les transactions.
le non dit évident dans cet affaire, c'est qu'on écrit pas du code toute les
3 lignes dans ses programmes pour donner la main à un autre processus (ça
s'appelle swaper). on en écrit même pas du tout. un processus ne doit pas
avoir "conscience" qu'on passe a un autre programme. c'est l'ordonanceur (le
systeme) qui décide de tout ça. et dieu sait qu'il est bien avisé.
voila, c'est la base du multi-threadind.
COM est une specification et une implantation. "ça" fourni des comportements
et des formalismes pour réaliser des mécanismes clients / serveurs.
et ça a quelques vertus : interoperabilité entre langages, objets distants
ou locaux sans pisser une ligne de code.
( je prefere m'assurer de ce que je crois savoir )
c'est louable.
j'espere quand même ne pas vous avoir trop saoulé avec des évidences.
et comment
s'assurer qu'une dll le gere sans problemes ou plus exactement que les
objects COM de ma dll gere correctement cela ??
c'est du COM, donc ils ont obligatoirement un modele de Thread (appartment,
etc).
tout objet COM a les propriétés offertes par COM.
maintenant, le "correct" est une notion qui dépend d'un peu plus que d'être
ou ne pas être des objets COM.
et pour savoir si c'est du COM, c'est simple, vous importer une lib COM, et
vous vous faites jetter, ou alors ça vous fabrique les wrappers (classes et
interfaces) et la tlb (fichier de description. c'est comme un .h de C++,
mais pour le formalisme COM)
> Qui pourrait me donner une jolie explication en francais de ce qu'est le multithreading
le resumé en une phrase de 10 mots est source de confusions.
un ordinateur est un sequenceur. il execute des actions/instructions les unes apres les autres.
pour mettre en parallele deux taches, on achete deux ordinateurs.
mais si on veux faire tourner deux taches en meme temps sur un seul séquenceur, on utilise une technique qui s'appelle le multithreading.
c'est à dire que l'on charge les deux programmes (deux suites d'instructions), et qu'on execute l'instruction du 1°, puis celle du 2°, puis celle du 1°, puis....
la rapidité et la finesse du découpage donne l'illusion de simultaneité.
si les deux programmes sont independants tout va bien. les problemes commencent quand ils se partagent des resources. par exemple une liste, une entrée sortie, ou autre chose. on appelle ça la concurence. ça donne naissance (comme dans un sgbd puisque le probleme est similaire) à la notion de section critique qui a des similitudes avec les transactions.
le non dit évident dans cet affaire, c'est qu'on écrit pas du code toute les 3 lignes dans ses programmes pour donner la main à un autre processus (ça s'appelle swaper). on en écrit même pas du tout. un processus ne doit pas avoir "conscience" qu'on passe a un autre programme. c'est l'ordonanceur (le systeme) qui décide de tout ça. et dieu sait qu'il est bien avisé.
voila, c'est la base du multi-threadind.
COM est une specification et une implantation. "ça" fourni des comportements et des formalismes pour réaliser des mécanismes clients / serveurs. et ça a quelques vertus : interoperabilité entre langages, objets distants ou locaux sans pisser une ligne de code.
( je prefere m'assurer de ce que je crois savoir )
c'est louable. j'espere quand même ne pas vous avoir trop saoulé avec des évidences.
et comment s'assurer qu'une dll le gere sans problemes ou plus exactement que les objects COM de ma dll gere correctement cela ??
c'est du COM, donc ils ont obligatoirement un modele de Thread (appartment, etc). tout objet COM a les propriétés offertes par COM.
maintenant, le "correct" est une notion qui dépend d'un peu plus que d'être ou ne pas être des objets COM.
et pour savoir si c'est du COM, c'est simple, vous importer une lib COM, et vous vous faites jetter, ou alors ça vous fabrique les wrappers (classes et interfaces) et la tlb (fichier de description. c'est comme un .h de C++, mais pour le formalisme COM)
merci.
de rien, j'espere que ça va aider.
Dominique Vaufreydaz
Bonjour,
Ambassadeur Kosh wrote:
le resumé en une phrase de 10 mots est source de confusions. un ordinateur est un sequenceur. il execute des actions/instructions les unes apres les autres. pour mettre en parallele deux taches, on achete deux ordinateurs. mais si on veux faire tourner deux taches en meme temps sur un seul séquenceur, on utilise une technique qui s'appelle le multithreading.
Oui et non en fait, j'ai peur que cette explication porte a confusion voir plus bas...
le non dit évident dans cet affaire, c'est qu'on écrit pas du code toute les 3 lignes dans ses programmes pour donner la main à un autre processus (ça s'appelle swaper). on en écrit même pas du tout. un processus ne doit pas avoir "conscience" qu'on passe a un autre programme. c'est l'ordonanceur (le systeme) qui décide de tout ça. et dieu sait qu'il est bien avisé. voila, c'est la base du multi-threadind.
Y'a bien des notions de "threading" dans les processeur mais au niveau de la programmation de thread fait reference a ce que l'on nomme un processus *leger*. Donc Pour faire simple, il existe 2 type de processus. Les processus (process) et les processus legers (thread). L'idee general est toujours la parallelisation d'un traitement et le fonctionnement de l'ordonnancement est similaire et conforme a ce qu'expliquait notre cher ambassadeur. En fait, des processus contiennent des processus leger (plus ou moins mais sous Windows la nothion de thread est immediate, a son lancement un processus contient donc un thread - processus leger -). Donc des threads sont des processus legers ordonancés a l'interieur d'un processus - process -.
L'idee est que 2 process ne partage pas le meme espace memoire mais que 2 thread oui. En gros Si tu lances 2 fois le meme processus, la variable A est doublee : il en existe 2 instances. Si tu lances 2 thread dans un processus, la variable A fait reference au *meme* espace memoire et donc a exactement la meme chose.
Maintenant, est-ce qu'une DLL supporte le multithreading (ou support de plusieurs threads legers ???) ou dans d'autres jargons est thread safe, depends de la maniere dont elle est ecrite. Par exemple, une function qui utilise un buffer static, donc en memoire globale donc partager par tous les threads est rarement thread safe. en effet, si 2 threads appellent cette fonction en meme temps, ca va donner n'importe quoi. Pour resourdre ce genre de probleme, soit en prends des variables locales qui sont donc proprietes excluse du processus leger puisque dans sa pile d'execution. Si il est impossible de garantir cela, il existe toute une batterie de choses (mutex, semaphore, section critique, etc.) pour garantir la protection contre ce genre de chose.
A une certaines epoque, les fonctions comme printf et consors sous IBM mainframe pouvoir conduire a un "core dump" si elles etaient appelees en meme temps par plusieurs threads.
Voila. En esperant avoir ete clair et n'avoir pas raconte d'enormite. Qu'on me corrige dans ce cas.
Doms. -- Impose ta chance, serre ton bonheur et va vers ton risque. A te regarder, ils s'habitueront. René Char, Les Matinaux. ---- http://Dominique.Vaufreydaz.free.fr/ http://TitchKaRa.free.fr/ http://logiciels.ntfaqfr.com/
Bonjour,
Ambassadeur Kosh wrote:
le resumé en une phrase de 10 mots est source de confusions.
un ordinateur est un sequenceur. il execute des actions/instructions les
unes apres les autres.
pour mettre en parallele deux taches, on achete deux ordinateurs.
mais si on veux faire tourner deux taches en meme temps sur un seul
séquenceur, on utilise une technique qui s'appelle le multithreading.
Oui et non en fait, j'ai peur que cette explication porte a confusion
voir plus bas...
le non dit évident dans cet affaire, c'est qu'on écrit pas du code toute les
3 lignes dans ses programmes pour donner la main à un autre processus (ça
s'appelle swaper). on en écrit même pas du tout. un processus ne doit pas
avoir "conscience" qu'on passe a un autre programme. c'est l'ordonanceur (le
systeme) qui décide de tout ça. et dieu sait qu'il est bien avisé.
voila, c'est la base du multi-threadind.
Y'a bien des notions de "threading" dans les processeur mais
au niveau de la programmation de thread fait reference a ce que l'on nomme
un processus *leger*. Donc Pour faire simple, il existe 2 type
de processus. Les processus (process) et les processus legers (thread).
L'idee general est toujours la parallelisation d'un traitement et le
fonctionnement de l'ordonnancement est similaire et conforme a
ce qu'expliquait notre cher ambassadeur. En fait, des processus
contiennent des processus leger (plus ou moins mais sous Windows
la nothion de thread est immediate, a son lancement un processus
contient donc un thread - processus leger -). Donc des threads
sont des processus legers ordonancés a l'interieur d'un processus
- process -.
L'idee est que 2 process ne partage pas le meme espace memoire
mais que 2 thread oui. En gros Si tu lances 2 fois le meme processus,
la variable A est doublee : il en existe 2 instances. Si tu lances 2 thread
dans un processus, la variable A fait reference au *meme* espace
memoire et donc a exactement la meme chose.
Maintenant, est-ce qu'une DLL supporte le multithreading
(ou support de plusieurs threads legers ???) ou dans d'autres jargons
est thread safe, depends de la maniere dont elle est ecrite.
Par exemple, une function qui utilise un buffer static, donc en
memoire globale donc partager par tous les threads est rarement
thread safe. en effet, si 2 threads appellent cette fonction en
meme temps, ca va donner n'importe quoi. Pour resourdre
ce genre de probleme, soit en prends des variables locales
qui sont donc proprietes excluse du processus leger puisque
dans sa pile d'execution. Si il est impossible de garantir cela,
il existe toute une batterie de choses (mutex, semaphore, section
critique, etc.) pour garantir la protection contre ce genre de chose.
A une certaines epoque, les fonctions comme printf et consors
sous IBM mainframe pouvoir conduire a un "core dump" si
elles etaient appelees en meme temps par plusieurs threads.
Voila. En esperant avoir ete clair et n'avoir pas raconte
d'enormite. Qu'on me corrige dans ce cas.
Doms.
--
Impose ta chance, serre ton bonheur et va vers ton risque.
A te regarder, ils s'habitueront.
René Char, Les Matinaux.
----
http://Dominique.Vaufreydaz.free.fr/
http://TitchKaRa.free.fr/
http://logiciels.ntfaqfr.com/
le resumé en une phrase de 10 mots est source de confusions. un ordinateur est un sequenceur. il execute des actions/instructions les unes apres les autres. pour mettre en parallele deux taches, on achete deux ordinateurs. mais si on veux faire tourner deux taches en meme temps sur un seul séquenceur, on utilise une technique qui s'appelle le multithreading.
Oui et non en fait, j'ai peur que cette explication porte a confusion voir plus bas...
le non dit évident dans cet affaire, c'est qu'on écrit pas du code toute les 3 lignes dans ses programmes pour donner la main à un autre processus (ça s'appelle swaper). on en écrit même pas du tout. un processus ne doit pas avoir "conscience" qu'on passe a un autre programme. c'est l'ordonanceur (le systeme) qui décide de tout ça. et dieu sait qu'il est bien avisé. voila, c'est la base du multi-threadind.
Y'a bien des notions de "threading" dans les processeur mais au niveau de la programmation de thread fait reference a ce que l'on nomme un processus *leger*. Donc Pour faire simple, il existe 2 type de processus. Les processus (process) et les processus legers (thread). L'idee general est toujours la parallelisation d'un traitement et le fonctionnement de l'ordonnancement est similaire et conforme a ce qu'expliquait notre cher ambassadeur. En fait, des processus contiennent des processus leger (plus ou moins mais sous Windows la nothion de thread est immediate, a son lancement un processus contient donc un thread - processus leger -). Donc des threads sont des processus legers ordonancés a l'interieur d'un processus - process -.
L'idee est que 2 process ne partage pas le meme espace memoire mais que 2 thread oui. En gros Si tu lances 2 fois le meme processus, la variable A est doublee : il en existe 2 instances. Si tu lances 2 thread dans un processus, la variable A fait reference au *meme* espace memoire et donc a exactement la meme chose.
Maintenant, est-ce qu'une DLL supporte le multithreading (ou support de plusieurs threads legers ???) ou dans d'autres jargons est thread safe, depends de la maniere dont elle est ecrite. Par exemple, une function qui utilise un buffer static, donc en memoire globale donc partager par tous les threads est rarement thread safe. en effet, si 2 threads appellent cette fonction en meme temps, ca va donner n'importe quoi. Pour resourdre ce genre de probleme, soit en prends des variables locales qui sont donc proprietes excluse du processus leger puisque dans sa pile d'execution. Si il est impossible de garantir cela, il existe toute une batterie de choses (mutex, semaphore, section critique, etc.) pour garantir la protection contre ce genre de chose.
A une certaines epoque, les fonctions comme printf et consors sous IBM mainframe pouvoir conduire a un "core dump" si elles etaient appelees en meme temps par plusieurs threads.
Voila. En esperant avoir ete clair et n'avoir pas raconte d'enormite. Qu'on me corrige dans ce cas.
Doms. -- Impose ta chance, serre ton bonheur et va vers ton risque. A te regarder, ils s'habitueront. René Char, Les Matinaux. ---- http://Dominique.Vaufreydaz.free.fr/ http://TitchKaRa.free.fr/ http://logiciels.ntfaqfr.com/
Aurelien REGAT-BARREL
> A une certaines epoque, les fonctions comme printf et consors sous IBM mainframe pouvoir conduire a un "core dump" si elles etaient appelees en meme temps par plusieurs threads.
Même avec la CRT de MS c'est problématique il me semble. Si les signaux genre SIGINT ne sont pas pris en compte c'est que leur interception se fait via un control handler (SetConsoleCtrlHandler) qui s'exécute dans un nouveau thread, rendant une app console de base multithreadée...
-- Aurélien
> A une certaines epoque, les fonctions comme printf et consors
sous IBM mainframe pouvoir conduire a un "core dump" si
elles etaient appelees en meme temps par plusieurs threads.
Même avec la CRT de MS c'est problématique il me semble. Si les signaux
genre SIGINT ne sont pas pris en compte c'est que leur interception se fait
via un control handler (SetConsoleCtrlHandler) qui s'exécute dans un
nouveau thread, rendant une app console de base multithreadée...
> A une certaines epoque, les fonctions comme printf et consors sous IBM mainframe pouvoir conduire a un "core dump" si elles etaient appelees en meme temps par plusieurs threads.
Même avec la CRT de MS c'est problématique il me semble. Si les signaux genre SIGINT ne sont pas pris en compte c'est que leur interception se fait via un control handler (SetConsoleCtrlHandler) qui s'exécute dans un nouveau thread, rendant une app console de base multithreadée...
-- Aurélien
Dominique Vaufreydaz
Re,
Même avec la CRT de MS c'est problématique il me semble. Si les signaux genre SIGINT ne sont pas pris en compte c'est que leur interception se fait via un control handler (SetConsoleCtrlHandler) qui s'exécute dans un nouveau thread, rendant une app console de base multithreadée...
J'ai decouvert ca aussi... Le coup du control-c traiter dans une pile systeme (ca m'a bien fait c...r ;-D). D'ailleurs notons que meme sous Linux, un thow dans le traitement du signal control-C par dans les choux, alors que pour les autres signaux (pointeur nul, etc...), le thorw fonctionne bien et se situe dans la bonne pile... A ca, les longjmp, ca le fait pas toujours ! ;-P
Doms. -- Impose ta chance, serre ton bonheur et va vers ton risque. A te regarder, ils s'habitueront. René Char, Les Matinaux. ---- http://Dominique.Vaufreydaz.free.fr/ http://TitchKaRa.free.fr/ http://logiciels.ntfaqfr.com/
Re,
Même avec la CRT de MS c'est problématique il me semble. Si les signaux
genre SIGINT ne sont pas pris en compte c'est que leur interception se fait
via un control handler (SetConsoleCtrlHandler) qui s'exécute dans un
nouveau thread, rendant une app console de base multithreadée...
J'ai decouvert ca aussi... Le coup du control-c traiter dans une pile
systeme (ca m'a bien fait c...r ;-D). D'ailleurs notons que meme sous
Linux, un thow dans le traitement du signal control-C par dans
les choux, alors que pour les autres signaux (pointeur nul, etc...),
le thorw fonctionne bien et se situe dans la bonne pile...
A ca, les longjmp, ca le fait pas toujours ! ;-P
Doms.
--
Impose ta chance, serre ton bonheur et va vers ton risque.
A te regarder, ils s'habitueront.
René Char, Les Matinaux.
----
http://Dominique.Vaufreydaz.free.fr/
http://TitchKaRa.free.fr/
http://logiciels.ntfaqfr.com/
Même avec la CRT de MS c'est problématique il me semble. Si les signaux genre SIGINT ne sont pas pris en compte c'est que leur interception se fait via un control handler (SetConsoleCtrlHandler) qui s'exécute dans un nouveau thread, rendant une app console de base multithreadée...
J'ai decouvert ca aussi... Le coup du control-c traiter dans une pile systeme (ca m'a bien fait c...r ;-D). D'ailleurs notons que meme sous Linux, un thow dans le traitement du signal control-C par dans les choux, alors que pour les autres signaux (pointeur nul, etc...), le thorw fonctionne bien et se situe dans la bonne pile... A ca, les longjmp, ca le fait pas toujours ! ;-P
Doms. -- Impose ta chance, serre ton bonheur et va vers ton risque. A te regarder, ils s'habitueront. René Char, Les Matinaux. ---- http://Dominique.Vaufreydaz.free.fr/ http://TitchKaRa.free.fr/ http://logiciels.ntfaqfr.com/
