Problème avec les threads (synchrones et asynchrones)

Le
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.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Gilles TOURREAU
Le #12170221
Le Tue, 02 Oct 2007 11:51:02 +0200, 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.




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
Le #12170201
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

> 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



Publicité
Poster une réponse
Anonyme