Pas de Threads pour vous ! (dans les applications style Metro)

This article is available in english .

Comme dirait ce cuisinier, puisque vous avez probablement utilisé les threads de la mauvaise manière (comme Microsoft semble le penser), vous ne pourrez plus utiliser la classe Thread dans les applications Metro sous Windows 8. La classe n'est tout simplement plus la, tout comme Timer ou ThreadPool.

Cela pourrait vous choquer, mais cela fait en fait beaucoup de sens. Mais ne vous inquiétez pas, le concept d'exécution parallèle est toujours présent, il prend simplement la forme de tâches.

 

Pourquoi utiliser les Threads n'est pas bon pour vous

Les threads sont un outil très puissant, mais il y a un certain nombre de problèmes qui viennent avec :

  • Les exceptions non gérées dans les Threads, que ce soit depuis un Timer, une Thread ou une Thread du ThreadPool, mênent à la fin du processus
  • Utiliser Abort est plutot mauvais pour le process, et devrait être évité
  • Les développeurs ont tendance à utiliser Thread.Sleep pour attendre arbitrairement pour un temps défini constant qui sera très probablement incorrect, et qui va utiliser inutilement des cycles CPU pour gérer ces Threads qui ne font rien,
  • Les développeurs ont tendance à créer des systèmes complexes pour chainer des opérations entre threads, qui la plupart du temps échouent lamentablement.

Il existe d'autres scénarios à éviter, mais ce sont les principaux pour lesquels les Threads sont à éviter.

Cela fait des années que je recommende de rester le plus loin possible des Threads, au moins en ne les utilisant pas directement, pour toutes ces raisons.

 

Utiliser Task, exclusivement

Puisque Microsoft a pris le temps de repenser certains concepts qui avaient été introduits dans la BCL et le CLR original en 1999, ils ont probablement pensé qu'il était temps d'enlever la classe Thread à la faveur de la classe Task, qui rend des services bien plus efficaces et qui gère efficacement les cas que j'ai listé plus haut :

Toutes ces opérations se mélangent très bien avec la nouvelle fonctionnalité async de C#5, avec laquelle il est très simple d'attendre une Task.

 

ThreadPool et Timer déplacés vers WinRT

Le ThreadPool est en fait toujours la, et il en est de même pour Timer sous la forme de TheadPoolTimer, mais tous deux ont été déplacées vers WinRT.

ThreadPool est maintenant async awaitable, supporte les priorités, a l'instar de Task. Pour le moment, je ne vois pas de bonne raison de l'utiliser, puisque Task propose bien plus de fonctionnalités.

ThreadPoolTimer peut être intéressant, bien que les exceptions lancées dans ce contexte semblent être gérées de manière silencieuse par WinRT. Il me manque encore à trouver ou ces exceptions vont... Ceci étant, je recommende de ne pas l'utiliser, à la faveur de Observable.Timer des Reactive Extensions qui sont bien plus utiles que ce simple Timer.

 

Restes de Threads

Il reste cependant un endroit ou les Threads font encore surface dans la BCL.

Si l'on prend ce code C# :

public IEnumerable IteratorSample() 
{ 
    yield return 1; 
}

Une fonctionnalité que les iterators générés par le compilateur est qu'ils ne sont pas Thread Safe et doivent être utilisés sur la thread sur laquelle ils ont été créés. L'iterator capture alors la Thread originale, et vérifie que les appels suivants seront bien sur la même thread.

Si l'on regarde donc vers quoi le code est étendu à l'interne, en utilisant un compilateur C# sur .NET 4.0 et antérieur:

[DebuggerHidden] 
public d__0(int <>1__state) 
{ 
   this.<>1__state = <>1__state; 
   this.<>l__initialThreadId = Thread.CurrentThread.ManagedThreadId; 
}

Alors qu'avec .NET 4.5, ceci va être généré:

[DebuggerHidden] 
public d__0(int <>1__state) 
{ 
   this.<>1__state = <>1__state; 
   this.<>l__initialThreadId = Environment.CurrentManagedThreadId; 
}

Le code généré pour .NET 4.5 fait alors usage de la nouvelle propriété Environment.CurrentManagedThreadId, puisque les iterateurs ont malgré tout besoin du vrai Thread ID, même si la classe Thread n'existe plus.

Intéressant, n'est-ce pas ?

Cela a un désagréable effet de bord, cela dit. Du code C# compilé par un compilateur en dessous de .NET 4.5 n'est plus binairement compatible avec la BCL des applications style Metro. Mais ce n'est finalement pas gênant, puisque la plupart de la surface des API de .NET ont soit changé (pour être async seulement), été déplacées (comme l'API de reflection) ou bien ont tout simplement disparues (comme System.IO qui s'est déplacé dans WinRT). Vous aurez donc à adapter votre code, de toute façon.

Je suppose que l'équipe de C# a du se battre pour cette fonctionnalité afin de garder la compatibilité, et garder le même comportement que dans les précédentes version de C#. Et je suis content que cette propriété soit toujours la, puisque je l'utilise dans mon framework de logging.

Happy WinRT'ing !

Publié dimanche 25 mars 2012 17:30 par jay
Classé sous , , , ,
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :

Commentaires

# re: Pas de Threads pour vous ! (dans les applications style Metro) @ lundi 26 mars 2012 09:59

Pub done : http://www.c2i.fr/actualites/les-threads-dans-windows-8-metro (beau billet ;-))

richardc


Les 10 derniers blogs postés

- Après Montréal, ce sera Barcelone, rendez-vous à la European SharePoint Conference 2014 ! par Le blog de Patrick [MVP SharePoint] le 04-19-2014, 09:21

- Emportez votre sélection de la MSDN dans la poche ? par Blog de Jérémy Jeanson le 04-17-2014, 22:24

- [ #Office365 ] Pb de connexion du flux Yammer ajouté à un site SharePoint par Le blog de Patrick [MVP SharePoint] le 04-17-2014, 17:03

- NFluent & Data Annotations : coder ses propres assertions par Fathi Bellahcene le 04-17-2014, 16:54

- Installer un site ASP.net 32bits sur un serveur exécutant SharePoint 2013 par Blog de Jérémy Jeanson le 04-17-2014, 06:34

- [ SharePoint Summit Montréal 2014 ] Tests de montée en charge SharePoint par Le blog de Patrick [MVP SharePoint] le 04-16-2014, 20:44

- [ SharePoint Summit Montréal 2014 ] Bâtir un site web public avec Office 365 par Le blog de Patrick [MVP SharePoint] le 04-16-2014, 18:30

- Kinect + Speech Recognition + Eedomus = Dommy par Aurélien GALTIER le 04-16-2014, 17:17

- [ SharePoint Summit Montréal 2014 ] Une méthodologie simple pour concevoir vos applications OOTB SharePoint de A à Z par Le blog de Patrick [MVP SharePoint] le 04-16-2014, 16:51

- //Lean/ - Apprendre à faire des Apps Windows universelles par Blog de Jérémy Jeanson le 04-16-2014, 12:57