Le Post Infeeny

Les articles des consultants et experts Infeeny

Windows Runtime Internals: Understanding the Threading Model (4-107)

Session animée par Martyn Lovell

Le but de la session est de présenter pourquoi le threading est important et comment le theading est implémenté dans WinRT et qu’est-ce qui se cache derrière la façade.

La session commence par une démo en C++ nommée « Media Buttons » qui montre tout les threads créés automatiquement par le système.

Pourquoi on a besoin de threads :

  • Services connectés au monde
  • Application responsive
  • Expérience touch
  • Plusieurs cœurs

Comment Windows parallélise :

  • Kernel threads
  • Separate processes
  • Brokers
  • Async operations

 Windows threading model :

  • UI objects dans le thread UI
  • Le thread principal vi aussi longtemps que l’application
  • La plupart des autres objets peuvent être utilisés dans n’importe quel threads
  • La plupart du travail est passé au ThreadPool
  • Les objets Windows suivent des règles naturelles et familières
  • Vous contrôlez la durée de vit d’un thread

 Le thread UI :

  • Les interfaces utilisateurs ont des besoin spécians
    • On ne veux pas que OK soit appuyé pendant le OnCancel
  • Les objet UI sont naturellement sérialisés
  • Ne pas faire de long travail sur le thread UI
  • A la place il faut passer un maximum de travail au thread pool

Demo : Comportement du thread UI

 UI Thread reentrency :

  • Les objets sur le thread UI n’ont pas besoin de locking pour se protéger eux-mêmes
  • Les thread UI ne sont pas réentrants
  • Quand vous faite un appel à un autre thread/process, seul les threads logiquement connectés peuvent vous rappeler
  • Les threads UI ne peuvent pas s’appeler en même temps (rejeté au moment de l’appel dans Windows 8.1)
  • Utiliser un dispatcher ou un objet asynchrone pour éviter ce genre d’appels

Schéma d’explication du « Single-threaded apartment reentrancy ».

 UI Thread waiting :

  • Pas de délais autorisés sur les threads UI
  • Most classic waiting primitives are inappropriate (Windows tue les applications ne répondant plus)
  • A la place il faut appeler des primitives UI-safe (C# await, C++ create_task, JS promise)

Démo : Safe view shutdown (MultipleView Sample)

 Le UI thread Principal :

  • L’interface principale de l’application est toujours lancée dans le thread UI principal
  • Le thread UI principal est utilisé pour gérer l’état global de l’application
  • Les autres threads UI sont pour les documents et les contrats
  • Le thread UI principal est vivant tant jusqu’à ce que l’application meure

 Threading dans l’environnement HTML :

  • Tout les threads sont des threads UI (même les web workers sont single-threaded)
  • Tout les évènement et complétions sont délivrées là où elle ont commencées
  • Utilisez les api standard des applications web au lieu du WinRT Core*

Threading en XAML :

  • Les objets UI sont liés à un threads
  • Utilise le dispatcher to déplacer le travail de l’ui dans le thread UI
  • Tout l’arbre XAML est dans un seul thread
  • Les évènements sont dans le thread UI

Objects and threading

  • Les protocoles basiques de WinRT sont threading-agnostic (Iunknown, Iinspectable)
  • La plupart des objets WinRT n’ont pas besoin de marshaling
  • Même les références à des objets hors du processus (proxies) sont agiles dans WinRT
  • Donc même si le marshaling existe toujours il est rarement visible et ce délibérément

Marshaling :

  • Les objet décident comment ils se marshallent (IMarshal, INoMarshal contrôlent le marshalling)
  • Les objets WinRT généralement « opt-out of marshaling »
  • Tout les marshalers sont fournis par le système avec l’aide des données générés par le MIDL

Thread pool threads :

  • Là où le travail long est effectué
  • Ils sont alloués, étendues et schedulés par le système
  • Les opérations async de WinRT tournent générallement dedans
  • Toujours initialisés par WinRT

Schéma démo des callback sur des objets asynchrones

Les objets agiles :

  • Objets qui peuvent travailler dans n’importe quel thread ou process sans être marshalled
  • Ils ne peuvent stocker que des objets agiles
  • Pas de stockage de Iinspectables
  • Ils sont simple à manipuler
  • La plupart des objets WinRT sont agiles

Apartments :

  • Apartments sont des concepts COM qui groupent et contrôlent les durés de vie des objets
  • Ils existent dans WinRT mais sont maintenant largement inutiles et remplacés par les objets agiles
  • Trois apartment
    • ASTA
    • MTA
    • NTA (Neutral threaded apartment utilisés par WinRT)

Appels cross-threads :

  • Les appels WinRT sont délivrés seulement quand le thread est prêt
  • Les appels sont en compétitions avec les autres pour obtenir l’attention d’un thread
  • Win 8.1 change :
    • Les appels ne bloquent plus les input
    • Le scheduler autorise les priorisation des work items

Une session intéressante qui explique tout ce qui se passe dans WinRT au niveau du threading. Définitivement à voir et à revoir.

John Thiriet

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :