Reprise du message précédent :
Haaa enfin tu nous sort un bout de code.
Je testerais ca, je prefere deja ca au abort() que tu proposait.
 
(un bout de code vaut mieux qu'un discours pas clair, enervé et enervant du style "mais t'es nul tu vois pas" )

j'ai dit Abort() en disant que c'était propre.
J'ai dit à personne qu'il était nul, c'est vous qui vous échauffez pour rien, vous vous braquez sans même aller voir ce que c'est qu'un événement et comment on s'en sert. Soit disant qu'il ne sagit pas de synchronisation (cf. le titre). J'ai filé un exemple d'Abort qui me paraît explicitement négatif.

 
non, mais je n'avais que l'autoResetEvent en tete, en effet, le manual permet de faire ce genre de chose de manière correcte.    
Je reconnais que tu as raison, mais je préfere mes booleans (pause et actif activés) !
 
1) plus simple, portables
2) utilisé en Java, en win32 par des pros etc...
3) si tu actives les 2 booleens, pause et actif, ton thread ne fait plus rien => il part en sleep puis s'arrete.
4) meme si ton thread ne s'arrete pas immédiatement, il ne fait plus rien (il fini son Sleep()) et c'est tout. Ca ne dérange pas d'avoir un thread de plus qui est en pause, meme pour des grands nombres.
 
Bref, je change pas mes applis na  

1) c'est quoi ton histoire de de portabilité
2) les pros java utilise aussi des événements et pas des conneries de booléens. pour la raison déjà évoquée
3) rien compris
4) tu te trompes. imagine un epplication avec un thread périodique, qui récupère des données toutes les 2N secondes, dans le cas moyen, tu vas devoir attendre minimum N secondes avant la fermeture de ton application ou la fin de ton thread. on voit que tu n'as jamais utilisé des threads, quelque soit la langage, dans un contexte fortement parallèle (serveur par exemple)
 
et arrête tes bêtises « les pros font comme ça », t'es ridicule

 
pas tres propre c'est ce que tu voulais dire non ?
 

Qui de nous deux etait braqué sans vouloir lacher un exemple ?   Je t'en réclame un depuis des lustres.
Quand a la MSDN, la version sur le net a chanhé par rapport a la mienne qui date d'il y a 2 ans : l'exemple du manualreset n'y est pas.
 

 
Non, c'est pas de la synchro ! ya qu'un seul thread ici, toi dans ton exemple, tu en met 2, mais ca n'est pas demandé.
Dans son premier post, vnom parle de 1 thread.
 
Je suis désolé de t'avoir embété, mais là, à critiquer comme tu le faisais (les boolean c'est nul, les get-set ca pue) sans justification, tu commencais a me gonfler.  
Moralité : un bout de code et ca repart    
 
(d'ailleurs, je vois toujours pas quel est l'inconvénient majeur des booleans, a part etre trop simples et nuls à ton gout   )

non, il y a 3 thread dans mon exemple.
 
je trouve ça dommage de pas utiliser les propriété, c'est fait exprès. si tu vois pas le problème avec les booléens, c'est que tu sais pas lire.

 
Mais bien sur ! Et la marmotte
Portabilité => traduction d'une appli C# -> java ou l'inverse par exemple (d'ou l'utilité des get-set au passage   Mais les proprietes ca marche aussi hein)
 

 
Non ! désolé de te décevoir mais des que tu fais pause=true dans mon code, le thread n'effectue plus d'action puisque cette action est conditionnée par le boolean pause.
Je commence a avoir de serieux doutes sur ta capacité a lire ! (je vais pas dire ta capacité a coder, ce serait trop facile)
 

Noooooon, sans deconner !!! Je posterais comme un gros con pour te faire chier uniquement.    
 
Tu m'enerves, j'ai deja codé une belle appli client serveur pour mon boulot (stage de 7 mois) qui fonctoinnait trés bien avec 30 clients et des débits de 1 Mo par client, avec des threads derriere. Et je ne compte pas les applis pour l'école, certes moins évoluées, et les applis perso qui n'ont pas cette ampleur.
 
 

He bien si, je n'ai rien inventé, je n'ai fait que recopier du code dans des applis deja existantes.
 
Les event c'est bien, mais ya pas que ca comme solution.  
 
Ton histoire de "ton appli met 20s a s'arreter" n'est pas un pb dans la trés grande majorité des cas : la fenetre se ferme, le thread s'arrete plus tard et les ressources libérées. A part si tu as des pauses de 1mn et plus, je vois pas en quoi ca pose pb.
 
Neanmoins, je me répete : ta solution (celle de M$) est tres bien. La mienne aussi.

Tu m'enerves tellement que j'en ai oublié ma question :
 
en quoi est ce que le fait que le thread s'arrete efectivement X secondes plus tard te dérange ?
 
Tout dépends de l'utilisation des ressources utilisées par le thread je dirais, genre des trucs partagés, mais je ne vois pas trop le pb si on a des sleep courts.
 
Donc je me résume : ta solution est mieux pour des sleep longs (>5s), la mienne est valables pour les sleep courts (<5s).
Dans mon vieux jeu de pong (http://olivkta.free.fr/dev/GLPong/ [...] ave152.zip) je fais ca et les pauses etant courtes, ca pose no pb.
 
Au passage : si tu sais pas quoi faire, mates les source et dis moi ce que je dois changer pour améliorer le code, je suis un perfectionniste)

les propriété sont une fonctionnalité de C#, je comprends rien à tes histoires : ça ne pose aucun problème de portabilité.
 
allez, continue avec du // avec des booléens... si l'attente active ou bloquante te gène pas, c'est grave. d'ailleurs avec un booléen, dans un  contexte peu différent (on va dire 1 rédacteur, 2 lecteurs), tu aurais probablement une famine.
 
continue avec tes applis qui mettent plusieurs minutes à s'arrêter (qui est un problème dans la __majorité__ des cas). On va prendre en exemple ton Word chéri et Windows qui t'empêche de supprimer un fichier en cours d'utilisation. Après avoir fermer word, il te faudrait attendre qui sait, 5 minutes, le temps que l'auto-sauvegarde s'arrête et libère tout ... mais ça te dépasse ça apparemment.

ça prouve que la solution est moins bonne, même si, en effet, il n'y a pas mort d'homme

non mais ton utilisateur va perde son temps pour rien et ressource vont être retenues inutilement

oui c'est exactement mon avis.
 
moi même dans ma vie professionelle j'ai vu des serveurs servant à faire des transactions boursières codés avec des booléens pour synchroniser certains threads, mais je ne dis pas pour autant que c'est la meilleure méthode, loin de là
 
edit: quel beau style  

 
Grrrrr, si tu utilise une propriété C# et que tu veux passer ton application en Java pour la faire tourner sous Linux, tu es emmerdé non ? il te faut les remodifier à la main .... super
Je ne comprend pas que tu ne comprenne pas.
 
 

 
Je n'utiliserais pas des boolean pour synchroniser 2 threads, seulement pour les terminer.
 

Q
uand tu ferme ton appli, la fenetre principale disparait imédiatement, le thread principal de l'appli (celui qui gere les fenetres, tu le sais ca, hein, qu'il y en a un) se ferme lui aussi, et je m'arrange pour libérer les fichiers.
 
Si le thread encore vivant bloque un fichier, celui-ci ne le bloque que pour qques secondes car aucun de mes threads ne fais de pose > 5s, ca ne m'est jamais arrivé.
 

 
Arrete, je crois avoir en face de moi un linuxien boutonneux qui crache sur M$, comme je les hais.
 

 
Non mais ton imperméabilité aux solutions d'autrui me dépasse, ca oui.
(neanmoins, meme si ca me fais chier, je te repete que ta solution est tres bien. On m'accusera pas de ne pas etre honnete )

 
Ok, voila ton point de vue, pour une fois il est clair et non vindicatif. Je t'en remercie et reconnais qu'effectivement, c'est moins bon.

pourquoi tu veux porter ton appli C# en java ? de même qu'il y a ikvm, il pourrai y avoir l'inverse, ça ne pose strictement aucun problème. et si ton seule problème, c'est de traduire des propriétés en get/set (chose faisable automatiquement en 2minutes), t'as bien de la chance. perso je fais du C#, pas du Java, je ne me soucie pas des autres langages, sinon la liste des mots réservés est déjà plus longue que ce sujet.
 
et non ça n'a rien avoir avec quoi que ce soit : une bonne application libère les ressources dont elle n'a plus besoin. que ta fenêtre graphique se ferme ou pas, si ton appli maintient pendant 10minutes une connexion réseau inutile, c'est idiot. d'autant plus si ton appli n'accepte qu'une seul instance, tu es bloqué. on a jamais dit nulle par que ton thread devait durer 5sec. évidemment, si ta pause dure 50ms, ça ne va rien changer. mais dans la vie, c'est pas comme ça. moi je fais des applis avec des requetes à intervalle pouvant aller jusqu'à 2H. moi je ne comprends pas pourquoi ne pas utiliser les événements qui sont efficaces, extensibles et sures.
 
quand à mon acné, tu en fais ce que tu veux, tu as vraiment peu d'arguments si c'est la seule chose que tu trouves à dire.
 
astuce du jour : terminer une application, c'est attendre la fin des tous ses threads, c'est de la synchronisation que tu veux ou non.

2 heures ! Ben, c'est quand meme assez specifique et rare comme appli. Mes threads, il faut qu'ils bourrent et fasse leur boulot le plus vite possible, peu de pauses (dans le jeu de pong, la pause pour l'affichage est de 20ms si jme rapelle bien, pour les mouvements des objets idem).
 

 
mais je vais les utiliser, ne t'en fais pas. Vu que c'est tout aussi court que les boolean et simple, je vois pas pkoi je m'en priverais a l'avenir.
 

 
Moi, si! On m'a demandé, pour l'appli dont je parlais avant, d'essayer de rester au maximum portable et d'utiliser au minmimum les choses spécifiques au C# (d'ou la manie des get-set, les boolean quand ca pose pas de pb etc...)
Et passer de C# -> java dans ces conditions n'est pas bien dur, t'as que les IHM a recoder.
 

Tu pinailles   : ici on parlait juste de fermer 1 thread (et ca pour moi, c'est pas de la synchro). Fermer une appli avec plusieurs threads, ca c'est de la synchro, oui, mais c'est toi qui a dérivé dessus.
 
Incident clos, à moins que tu ne veuilles en rajouter une couche. Je noterais que : t'es assez facilement irritable, je comprend pas vite (mais sans code )