Problème avec les threads (synchrones et asynchrones)
2 réponses
Denis
Bonjour,
N'ayant pas l'habitude de travailler avec des threads, je bute sur un
problème d'organisation de thread (synchrones et asynchrones)
Voici mon problème:
Je souhaite créer une assembly dont le rôle est de me retourner toutes les
instances SQLServer (2000 et 2005) sur un réseau.
Pour chaque instance, avoir toutes les bases utilisateurs et pour chaque
base, les tables, vues et procédures stockées.
Le résultat de l'exploration des instances est retourné sous forme d'un
TreeNode.
Jusque là, pas de problème, SMO est là pour cela.
Comme l'exploration est longue, pour ne pas bloquer l'utilisation de
l'appli, je sous faire tourner une instance de mon assembly dans des threads.
Il faut organiser cela pour que :
- lorsque l'exploration des intances SQLServer démarre, un évenement est
envoyé à mon appli.
- lorsque une instance SQLServer est totalement explorée et que son treenode
est disponible, celui-ci(le treenode) est envoyé à l'appli (par un événement)
pour l'ajouter à un treeview.
- les explorations des instances doivent se faire en parallèle.
- lorsque tous les instances SQLServer ont été explorées, un dernier
événement est envoyé à l'appli pour signaler la fin de toutes les
explorations.
J'ai exploré la piste du pool de thread, qui me semble être là pour cela
(les threads sont exécutés en parallèle de façon asynchrone)
Ce que j'ai fait:
Dans mon assembly, une méthode (M1) qui créer un thread pour une méthode M2
dont la fonction est de détecter toutes les instances SQLServer. Lorsque M1
se lance, elle génère un évément "Demarré" pour l'appli, créer le thread pour
M2, lance le thread et génère un événement "en cours" pour l'appli.
M2 recherche toutes les instances (DataTable serveurs =
SmoApplication.EnumAvailableSqlServers()), puis pour chaque serveur, créer un
objet "SQLInstance" et l'ajoute dans un pool de thread. Cet objet SQLInstance
recoit le nom de l'instance SQLServer qu'il doit explorer.
Soit cette instance de mon objet "SQLInstance" balaye l'instance SQLServer
dans un thread, au quel cas toutes les recherches se font bien en parallèle
mais du coup, tous les threads du pool envoyent le signal de fin trop tôt ,
soit ce balayage n'est pas dans un thread et les explorations ne s'exécutent
plus en parallèle.
A force de tout essayer, je pense qu'une bonne réorganisation est nécessaire.
Si quelqu'un peu m'aider la dessus, j'en serais ravi.
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
Gilles TOURREAU
Le Tue, 02 Oct 2007 11:51:02 +0200, Denis a écrit:
Bonjour,
N'ayant pas l'habitude de travailler avec des threads, je bute sur un problème d'organisation de thread (synchrones et asynchrones)
Voici mon problème:
Je souhaite créer une assembly dont le rôle est de me retourner toutes les instances SQLServer (2000 et 2005) sur un réseau. Pour chaque instance, avoir toutes les bases utilisateurs et pour chaque base, les tables, vues et procédures stockées. Le résultat de l'exploration des instances est retourné sous forme d'un TreeNode. Jusque là, pas de problème, SMO est là pour cela.
Comme l'exploration est longue, pour ne pas bloquer l'utilisation de l'appli, je sous faire tourner une instance de mon assembly dans des threads.
Il faut organiser cela pour que : - lorsque l'exploration des intances SQLServer démarre, un évenement est envoyé à mon appli. - lorsque une instance SQLServer est totalement explorée et que son treenode est disponible, celui-ci(le treenode) est envoyé à l'appli (par un événement) pour l'ajouter à un treeview. - les explorations des instances doivent se faire en parallèle. - lorsque tous les instances SQLServer ont été explorées, un dernier événement est envoyé à l'appli pour signaler la fin de toutes les explorations.
J'ai exploré la piste du pool de thread, qui me semble être là pour cela (les threads sont exécutés en parallèle de façon asynchrone)
Ce que j'ai fait:
Dans mon assembly, une méthode (M1) qui créer un thread pour une méthode M2 dont la fonction est de détecter toutes les instances SQLServer. Lorsque M1 se lance, elle génère un évément "Demarré" pour l'appli, créer le thread pour M2, lance le thread et génère un événement "en cours" pour l'appli.
M2 recherche toutes les instances (DataTable serveurs > SmoApplication.EnumAvailableSqlServers()), puis pour chaque serveur, créer un objet "SQLInstance" et l'ajoute dans un pool de thread. Cet objet SQLInstance recoit le nom de l'instance SQLServer qu'il doit explorer.
Soit cette instance de mon objet "SQLInstance" balaye l'instance SQLServer dans un thread, au quel cas toutes les recherches se font bien en parallèle mais du coup, tous les threads du pool envoyent le signal de fin trop tôt , soit ce balayage n'est pas dans un thread et les explorations ne s'exécutent plus en parallèle.
A force de tout essayer, je pense qu'une bonne réorganisation est nécessaire.
Si quelqu'un peu m'aider la dessus, j'en serais ravi.
Je ne vois pas pourquoi créer un pool de Thread pour votre cas... Un simple tableau de Thread géré par le thread principal suffit...
Cordialement
-- Gilles TOURREAU
S.A.R.L. P.O.S Le spécialiste en motoculture depuis + de 30 ans ! http://www.pos.fr
Le Tue, 02 Oct 2007 11:51:02 +0200, Denis
<Denis@discussions.microsoft.com> a écrit:
Bonjour,
N'ayant pas l'habitude de travailler avec des threads, je bute sur un
problème d'organisation de thread (synchrones et asynchrones)
Voici mon problème:
Je souhaite créer une assembly dont le rôle est de me retourner toutes
les
instances SQLServer (2000 et 2005) sur un réseau.
Pour chaque instance, avoir toutes les bases utilisateurs et pour chaque
base, les tables, vues et procédures stockées.
Le résultat de l'exploration des instances est retourné sous forme d'un
TreeNode.
Jusque là, pas de problème, SMO est là pour cela.
Comme l'exploration est longue, pour ne pas bloquer l'utilisation de
l'appli, je sous faire tourner une instance de mon assembly dans des
threads.
Il faut organiser cela pour que :
- lorsque l'exploration des intances SQLServer démarre, un évenement est
envoyé à mon appli.
- lorsque une instance SQLServer est totalement explorée et que son
treenode
est disponible, celui-ci(le treenode) est envoyé à l'appli (par un
événement)
pour l'ajouter à un treeview.
- les explorations des instances doivent se faire en parallèle.
- lorsque tous les instances SQLServer ont été explorées, un dernier
événement est envoyé à l'appli pour signaler la fin de toutes les
explorations.
J'ai exploré la piste du pool de thread, qui me semble être là pour cela
(les threads sont exécutés en parallèle de façon asynchrone)
Ce que j'ai fait:
Dans mon assembly, une méthode (M1) qui créer un thread pour une méthode
M2
dont la fonction est de détecter toutes les instances SQLServer. Lorsque
M1
se lance, elle génère un évément "Demarré" pour l'appli, créer le thread
pour
M2, lance le thread et génère un événement "en cours" pour l'appli.
M2 recherche toutes les instances (DataTable serveurs > SmoApplication.EnumAvailableSqlServers()), puis pour chaque serveur,
créer un
objet "SQLInstance" et l'ajoute dans un pool de thread. Cet objet
SQLInstance
recoit le nom de l'instance SQLServer qu'il doit explorer.
Soit cette instance de mon objet "SQLInstance" balaye l'instance
SQLServer
dans un thread, au quel cas toutes les recherches se font bien en
parallèle
mais du coup, tous les threads du pool envoyent le signal de fin trop
tôt ,
soit ce balayage n'est pas dans un thread et les explorations ne
s'exécutent
plus en parallèle.
A force de tout essayer, je pense qu'une bonne réorganisation est
nécessaire.
Si quelqu'un peu m'aider la dessus, j'en serais ravi.
Je ne vois pas pourquoi créer un pool de Thread pour votre cas...
Un simple tableau de Thread géré par le thread principal suffit...
Cordialement
--
Gilles TOURREAU
gilles.tourreau@pos.fr
S.A.R.L. P.O.S
Le spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr
Le Tue, 02 Oct 2007 11:51:02 +0200, Denis a écrit:
Bonjour,
N'ayant pas l'habitude de travailler avec des threads, je bute sur un problème d'organisation de thread (synchrones et asynchrones)
Voici mon problème:
Je souhaite créer une assembly dont le rôle est de me retourner toutes les instances SQLServer (2000 et 2005) sur un réseau. Pour chaque instance, avoir toutes les bases utilisateurs et pour chaque base, les tables, vues et procédures stockées. Le résultat de l'exploration des instances est retourné sous forme d'un TreeNode. Jusque là, pas de problème, SMO est là pour cela.
Comme l'exploration est longue, pour ne pas bloquer l'utilisation de l'appli, je sous faire tourner une instance de mon assembly dans des threads.
Il faut organiser cela pour que : - lorsque l'exploration des intances SQLServer démarre, un évenement est envoyé à mon appli. - lorsque une instance SQLServer est totalement explorée et que son treenode est disponible, celui-ci(le treenode) est envoyé à l'appli (par un événement) pour l'ajouter à un treeview. - les explorations des instances doivent se faire en parallèle. - lorsque tous les instances SQLServer ont été explorées, un dernier événement est envoyé à l'appli pour signaler la fin de toutes les explorations.
J'ai exploré la piste du pool de thread, qui me semble être là pour cela (les threads sont exécutés en parallèle de façon asynchrone)
Ce que j'ai fait:
Dans mon assembly, une méthode (M1) qui créer un thread pour une méthode M2 dont la fonction est de détecter toutes les instances SQLServer. Lorsque M1 se lance, elle génère un évément "Demarré" pour l'appli, créer le thread pour M2, lance le thread et génère un événement "en cours" pour l'appli.
M2 recherche toutes les instances (DataTable serveurs > SmoApplication.EnumAvailableSqlServers()), puis pour chaque serveur, créer un objet "SQLInstance" et l'ajoute dans un pool de thread. Cet objet SQLInstance recoit le nom de l'instance SQLServer qu'il doit explorer.
Soit cette instance de mon objet "SQLInstance" balaye l'instance SQLServer dans un thread, au quel cas toutes les recherches se font bien en parallèle mais du coup, tous les threads du pool envoyent le signal de fin trop tôt , soit ce balayage n'est pas dans un thread et les explorations ne s'exécutent plus en parallèle.
A force de tout essayer, je pense qu'une bonne réorganisation est nécessaire.
Si quelqu'un peu m'aider la dessus, j'en serais ravi.
Je ne vois pas pourquoi créer un pool de Thread pour votre cas... Un simple tableau de Thread géré par le thread principal suffit...
Cordialement
-- Gilles TOURREAU
S.A.R.L. P.O.S Le spécialiste en motoculture depuis + de 30 ans ! http://www.pos.fr
Denis
Bonjour,
C'est vrai qu'après avoir posté le message, je n'étais plus convaincu que le pool de thread servirait à quelque chose.
2nis
"Gilles TOURREAU" wrote:
Le Tue, 02 Oct 2007 11:51:02 +0200, Denis a écrit:
> Bonjour, > > N'ayant pas l'habitude de travailler avec des threads, je bute sur un > problème d'organisation de thread (synchrones et asynchrones) > > Voici mon problème: > > Je souhaite créer une assembly dont le rôle est de me retourner toutes > les > instances SQLServer (2000 et 2005) sur un réseau. > Pour chaque instance, avoir toutes les bases utilisateurs et pour chaque > base, les tables, vues et procédures stockées. > Le résultat de l'exploration des instances est retourné sous forme d'un > TreeNode. > Jusque là, pas de problème, SMO est là pour cela. > > Comme l'exploration est longue, pour ne pas bloquer l'utilisation de > l'appli, je sous faire tourner une instance de mon assembly dans des > threads. > > Il faut organiser cela pour que : > - lorsque l'exploration des intances SQLServer démarre, un évenement est > envoyé à mon appli. > - lorsque une instance SQLServer est totalement explorée et que son > treenode > est disponible, celui-ci(le treenode) est envoyé à l'appli (par un > événement) > pour l'ajouter à un treeview. > - les explorations des instances doivent se faire en parallèle. > - lorsque tous les instances SQLServer ont été explorées, un dernier > événement est envoyé à l'appli pour signaler la fin de toutes les > explorations. > > J'ai exploré la piste du pool de thread, qui me semble être là pour cela > (les threads sont exécutés en parallèle de façon asynchrone) > > > > Ce que j'ai fait: > > Dans mon assembly, une méthode (M1) qui créer un thread pour une méthode > M2 > dont la fonction est de détecter toutes les instances SQLServer. Lorsque > M1 > se lance, elle génère un évément "Demarré" pour l'appli, créer le thread > pour > M2, lance le thread et génère un événement "en cours" pour l'appli. > > M2 recherche toutes les instances (DataTable serveurs > > SmoApplication.EnumAvailableSqlServers()), puis pour chaque serveur, > créer un > objet "SQLInstance" et l'ajoute dans un pool de thread. Cet objet > SQLInstance > recoit le nom de l'instance SQLServer qu'il doit explorer. > > Soit cette instance de mon objet "SQLInstance" balaye l'instance > SQLServer > dans un thread, au quel cas toutes les recherches se font bien en > parallèle > mais du coup, tous les threads du pool envoyent le signal de fin trop > tôt , > soit ce balayage n'est pas dans un thread et les explorations ne > s'exécutent > plus en parallèle. > > A force de tout essayer, je pense qu'une bonne réorganisation est > nécessaire. > > Si quelqu'un peu m'aider la dessus, j'en serais ravi. >
Je ne vois pas pourquoi créer un pool de Thread pour votre cas... Un simple tableau de Thread géré par le thread principal suffit...
Cordialement
-- Gilles TOURREAU
S.A.R.L. P.O.S Le spécialiste en motoculture depuis + de 30 ans ! http://www.pos.fr
Bonjour,
C'est vrai qu'après avoir posté le message, je n'étais plus convaincu que le
pool de thread servirait à quelque chose.
2nis
"Gilles TOURREAU" wrote:
Le Tue, 02 Oct 2007 11:51:02 +0200, Denis
<Denis@discussions.microsoft.com> a écrit:
> Bonjour,
>
> N'ayant pas l'habitude de travailler avec des threads, je bute sur un
> problème d'organisation de thread (synchrones et asynchrones)
>
> Voici mon problème:
>
> Je souhaite créer une assembly dont le rôle est de me retourner toutes
> les
> instances SQLServer (2000 et 2005) sur un réseau.
> Pour chaque instance, avoir toutes les bases utilisateurs et pour chaque
> base, les tables, vues et procédures stockées.
> Le résultat de l'exploration des instances est retourné sous forme d'un
> TreeNode.
> Jusque là, pas de problème, SMO est là pour cela.
>
> Comme l'exploration est longue, pour ne pas bloquer l'utilisation de
> l'appli, je sous faire tourner une instance de mon assembly dans des
> threads.
>
> Il faut organiser cela pour que :
> - lorsque l'exploration des intances SQLServer démarre, un évenement est
> envoyé à mon appli.
> - lorsque une instance SQLServer est totalement explorée et que son
> treenode
> est disponible, celui-ci(le treenode) est envoyé à l'appli (par un
> événement)
> pour l'ajouter à un treeview.
> - les explorations des instances doivent se faire en parallèle.
> - lorsque tous les instances SQLServer ont été explorées, un dernier
> événement est envoyé à l'appli pour signaler la fin de toutes les
> explorations.
>
> J'ai exploré la piste du pool de thread, qui me semble être là pour cela
> (les threads sont exécutés en parallèle de façon asynchrone)
>
>
>
> Ce que j'ai fait:
>
> Dans mon assembly, une méthode (M1) qui créer un thread pour une méthode
> M2
> dont la fonction est de détecter toutes les instances SQLServer. Lorsque
> M1
> se lance, elle génère un évément "Demarré" pour l'appli, créer le thread
> pour
> M2, lance le thread et génère un événement "en cours" pour l'appli.
>
> M2 recherche toutes les instances (DataTable serveurs > > SmoApplication.EnumAvailableSqlServers()), puis pour chaque serveur,
> créer un
> objet "SQLInstance" et l'ajoute dans un pool de thread. Cet objet
> SQLInstance
> recoit le nom de l'instance SQLServer qu'il doit explorer.
>
> Soit cette instance de mon objet "SQLInstance" balaye l'instance
> SQLServer
> dans un thread, au quel cas toutes les recherches se font bien en
> parallèle
> mais du coup, tous les threads du pool envoyent le signal de fin trop
> tôt ,
> soit ce balayage n'est pas dans un thread et les explorations ne
> s'exécutent
> plus en parallèle.
>
> A force de tout essayer, je pense qu'une bonne réorganisation est
> nécessaire.
>
> Si quelqu'un peu m'aider la dessus, j'en serais ravi.
>
Je ne vois pas pourquoi créer un pool de Thread pour votre cas...
Un simple tableau de Thread géré par le thread principal suffit...
Cordialement
--
Gilles TOURREAU
gilles.tourreau@pos.fr
S.A.R.L. P.O.S
Le spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr
C'est vrai qu'après avoir posté le message, je n'étais plus convaincu que le pool de thread servirait à quelque chose.
2nis
"Gilles TOURREAU" wrote:
Le Tue, 02 Oct 2007 11:51:02 +0200, Denis a écrit:
> Bonjour, > > N'ayant pas l'habitude de travailler avec des threads, je bute sur un > problème d'organisation de thread (synchrones et asynchrones) > > Voici mon problème: > > Je souhaite créer une assembly dont le rôle est de me retourner toutes > les > instances SQLServer (2000 et 2005) sur un réseau. > Pour chaque instance, avoir toutes les bases utilisateurs et pour chaque > base, les tables, vues et procédures stockées. > Le résultat de l'exploration des instances est retourné sous forme d'un > TreeNode. > Jusque là, pas de problème, SMO est là pour cela. > > Comme l'exploration est longue, pour ne pas bloquer l'utilisation de > l'appli, je sous faire tourner une instance de mon assembly dans des > threads. > > Il faut organiser cela pour que : > - lorsque l'exploration des intances SQLServer démarre, un évenement est > envoyé à mon appli. > - lorsque une instance SQLServer est totalement explorée et que son > treenode > est disponible, celui-ci(le treenode) est envoyé à l'appli (par un > événement) > pour l'ajouter à un treeview. > - les explorations des instances doivent se faire en parallèle. > - lorsque tous les instances SQLServer ont été explorées, un dernier > événement est envoyé à l'appli pour signaler la fin de toutes les > explorations. > > J'ai exploré la piste du pool de thread, qui me semble être là pour cela > (les threads sont exécutés en parallèle de façon asynchrone) > > > > Ce que j'ai fait: > > Dans mon assembly, une méthode (M1) qui créer un thread pour une méthode > M2 > dont la fonction est de détecter toutes les instances SQLServer. Lorsque > M1 > se lance, elle génère un évément "Demarré" pour l'appli, créer le thread > pour > M2, lance le thread et génère un événement "en cours" pour l'appli. > > M2 recherche toutes les instances (DataTable serveurs > > SmoApplication.EnumAvailableSqlServers()), puis pour chaque serveur, > créer un > objet "SQLInstance" et l'ajoute dans un pool de thread. Cet objet > SQLInstance > recoit le nom de l'instance SQLServer qu'il doit explorer. > > Soit cette instance de mon objet "SQLInstance" balaye l'instance > SQLServer > dans un thread, au quel cas toutes les recherches se font bien en > parallèle > mais du coup, tous les threads du pool envoyent le signal de fin trop > tôt , > soit ce balayage n'est pas dans un thread et les explorations ne > s'exécutent > plus en parallèle. > > A force de tout essayer, je pense qu'une bonne réorganisation est > nécessaire. > > Si quelqu'un peu m'aider la dessus, j'en serais ravi. >
Je ne vois pas pourquoi créer un pool de Thread pour votre cas... Un simple tableau de Thread géré par le thread principal suffit...
Cordialement
-- Gilles TOURREAU
S.A.R.L. P.O.S Le spécialiste en motoculture depuis + de 30 ans ! http://www.pos.fr
