Exemples de performances médiocres pouvant être corrigées par multithreading

Question

Cette question est assez générale, mais je suis un programmeur débutant-intermédiaire qui vient de terminer une classe d'applications et l'un de ses sujets était le multithreading. Nous avons fait plusieurs devoirs qui impliquaient de créer des interfaces graphiques avec des boutons qui démarreraient un long processus (lecture d'une base de données, etc.).

Dans ces cas, nous créerions des versions mono et multithread dans lesquelles la tâche d'effectuer le traitement était sur un thread distinct de tout le reste, de sorte que lorsque le bouton était enfoncé, l'application ne bloquait pas.

A ma question:

Au travail aujourd'hui, je fait une recherche dans mon MS Outlook pour un mot spécifique dans l'espoir de trouver un e-mail spécifique; malheureusement le mot était commun et cent millions d'e-mails sont apparus. Il y a un bouton d'arrêt, mais l'appuyer n'a absolument rien fait ...

D'après mon expérience en classe, n'est-ce pas là un exemple où le fait de placer le processus de recherche sur son propre fil ne causerait pas le problème ci-dessus? Sûrement Microsoft ne ferait pas quelque chose de stupide comme ça ... y a-t-il une raison pour que ce ne soit pas son propre fil? Si c'est son propre thread, alors pourquoi l'application décrocherait-elle et ne répondrait pas au bouton d'arrêt? (Raisons liées au système d'exploitation?).

Tout cela était sur un système double cœur Windows XP 32 bits, si c'est pertinent. Vraiment, je veux juste mieux comprendre où le multithreading entre en jeu et comment apprendre où l'appliquer. Existe-t-il des exemples d'applications bien connues qui bénéficient clairement du multithreading? Est-il vraiment possible de distinguer clairement?

Merci!

R

Answer 1

Il est tout à fait possible que la recherche était, en effet, dans un autre thread, mais passer les résultats au fil principal et les dessin a été fait embourber le fil conducteur assez qu'il n'a pas le temps de répondre à vos demandes. La seule solution que je connaisse pour un problème comme celui-ci est de limiter le nombre de résultats que le processus de recherche peut renvoyer. Si vous ne souhaitez pas limiter le nombre de résultats, dessinez le volet des messages dans un fil différent. Cependant, c'est très difficile, car la plupart des toolkits gui sont mono-thread. De plus, même dans ce cas, le fil pourrait (dans les cas extrêmes) prendre tellement de mémoire qu'il a ralenti le gui principal.

Answer 2

Chaque fois que vous voyez un écran de démarrage pour une application, c'est un grand indicateur que quelque chose se passe sur un fil séparé.

Ceci est plus pour un usage esthétique, mais cela aide l'utilisateur à comprendre que la machine n'est pas bloquée pendant que les processus se chargent en arrière-plan.