Discussion :

[Silvia12]

Bonjour,

J'ai besoin de faire un petit projet, et j'aimerais un peu d'aide car je suis un peu perdu.

Je vous explique le but du projet.

Réaliser une petite interface qui génère des commandes et les enregistre vers une base de donnée (SQL Serveur via les objets métier de SAGE pour les connaisseur).
Vu que l'enregistrement est un peu long, le but et d'effectuer l'enregistrement simultanément la saisie d'une nouvelle commande.

Pour cela, je ne vois pas les thread. Mais, je sais pas trop comment réaliser le truc...
Le thread va tournée en boucle dernière le programme est a chaque validation, enregistrer la commande... (il se peu même qu'il y est plusieurs commande en attente d'enregistrement)


Le truc qui va me poser souci c'est lors de la fermeture du logiciel, comment terminer le thread ? Être sur qu'il est pas en train d'enregistrer une commence a se moment la...
Ai je besoin d'utiliser une sémaphore? même si j'ai pas trop compris le fonctionnement... ^^

Si quelqu'un peu m'éclairer sur le traitement à faire ??
Je sais pas trop non plus dans quoi stocker ma commande en attente??

merci d'avance

[bacelar]

C'est assez général comme demande.

Je te propose cette architecture.

1 thread principal, celui de l'IHM (créé automatiquement par l'OS)
1 thread auxiliaire, en charge des communications asynchrones avec le BD.

2 objets Event partagés entre les deux threads, pas besoin d'une structure d'exclusion mutelle pour ces objets. 1 Event "Nouvelle Tâche" et 1 Event "C'est Fini". L'évènement "Nouvelle Tâche" sera en "autoreset".
1 structure de données type file partagées entre les deux threads, soit la strurture est thread-safe, soit protégé par un mécanisme d'exclusion mutuelle comme un mutex ou un sémaphore.

Lors d'une demande vers la base, le thread principal acquiert le mutex de protection à la structure de données, y ajoute une nouvelle tâche, libère le mutex et déclenche l'évènement "Nouvelle Tâche".
A la fin de l'application, le thread principal déclenche l'évènement "C'est Fini" et attend sur l'handler du thread auxiliaire qui sera automatiquement "signalé" à la fin du thread auxiliaire.

Le thread auxiliaire boucle en attendant simultanément les Events
"Nouvelle Tâche" et "C'est Fini". Si c'est l'évènement "C'est Fini" qui se déclenche, il sort de sa boucle et s'arrête. Si c'est l'évènement "Nouvelle Tâche" qui se déclenche, le thread auxiliaire acquiert le mutex de protection à la structure de données, y récupérer TOUTES les tâches à faire, il les exécute une à une et revient en attente des 2 Events quand il ne reste plus de tâches récupérées (ne pas lire dans la structure de données partagés à ce moment là).

[Laurent Dardenne]

Il me semble que vous partez du principe que le traitement du thread, réussira toujours.

Le truc qui va me poser souci ...

S'il n'y avait que celui-ci
Une régle de gestions peut se déclencher lors de l'insertion, réseau hs, temps de réponse excessif du SGBD.

J'ai comme l'impression qu'avant d'être un pb technique il y a un problème d'analyse.

[Mac LAK]

Si c'est juste pour arrêter proprement un thread qui tourne constamment, un simple booléen global (couplé à la destruction des objets de synchro pour débloquer les threads en attente) peut largement suffire...

[Médinoc]

Si c'est juste pour arrêter proprement un thread qui tourne constamment, un simple booléen global (couplé à la destruction des objets de synchro pour débloquer les threads en attente) peut largement suffire...

J'utiliserais plutôt un Event.

[Mac LAK]

Un event "coûte" des ressources, de l'initialisation, etc. tandis qu'un bête booléen mis à jour depuis le thread principal et lu uniquement depuis les threads (=> pas de souci de conflit d'accès) reste bien plus simple : dans ce cas, il suffit juste de détruire les objets de synchro afin de libérer les threads en attente, puis de tester ce flag après la sortie du Wait en condition WAIT_ABANDONED, ainsi qu'en début de boucle du thread... Pas vraiment plus de code (en pratique, bien moins d'ailleurs) qu'avec un event.

Après, c'est valable pour une procédure de sortie de programme, ça l'est un peu moins pour arrêter spécifiquement UN thread donné parmi plein d'autres devant rester actifs (et encore, c'est pas non plus évident...).

[Médinoc]

Quand même, détruire les objets de synchronisation quand les autres threads attendent dessus, ça me parait un peu crade (même si je l'ai moi-même fait, sur un handle dupliqué de l'entrée console).

[Mac LAK]

Quand même, détruire les objets de synchronisation quand les autres threads attendent dessus, ça me parait un peu crade (même si je l'ai moi-même fait, sur un handle dupliqué de l'entrée console).

En quoi c'est crade ?? C'est un cas normal et prévu, certes dégradé, mais tout à fait légitime. La preuve, la constante symbolique retournée dans un tel cas est très différente d'un échec !

Et heureusement, d'ailleurs : imagines un peu le bronx avec un objet de synchro détruit par erreur/hasard (pointeur "intelligent" en mode idiot, par exemple) et tous les threads en attente dessus qui crashent instantanément...

[Médinoc]

En quoi c'est crade ?? C'est un cas normal et prévu, certes dégradé, mais tout à fait légitime. La preuve, la constante symbolique retournée dans un tel cas est très différente d'un échec !

Je n'ai jamais essayé spécialement avec les objets de synchronisation, mais je n'ai pas vu ça non plus dans la doc: Dans mes souvenirs, WAIT_ABANDONED_0 n'est évoqué que pour les mutexes abandonnés, qui sont les mutexes dont le thread "propriétaire" s'est terminé avant de les avoir libérés.

Et pour ma tricherie avec un flux, la valeur retournée était celle d'un échec (ERROR_INVALID_HANDLE). Mais ça ne prouve rien, vu que je bloquais sur ReadConsole() et non sur une fonction d'attente.