Réponse

Dans VB.NET, les mécanismes de multithreading disponibles sont :

• La classe Thread (System.Threading.Thread) — création et lancement manuel des threads. Nécessite une gestion détaillée, adaptée aux scénarios simples.
• La classe BackgroundWorker — pratique pour les opérations asynchrones dans les applications Windows Forms (l'UI reste réactive).
• L'espace de noms Task Parallel Library (TPL), y compris les classes Task et le mot-clé Async/Await. Approche moderne et recommandée.

Synchronisation :

• Moniteurs (SyncLock), mutex, sémaphores — pour protéger les sections critiques et l'accès aux ressources partagées.

Exemple :

' Lancement d'une tâche parallèle
Imports System.Threading.Tasks

Sub StartJob()
    Task.Run(Sub()
        ' Opération longue
        Console.WriteLine("Travail dans un thread séparé")
    End Sub)
End Sub

' Utilisation de SyncLock pour la synchronisation
Dim locker As New Object()

Sub SafeIncrement()
    SyncLock locker
        ' Le code ici s'exécute de manière atomique
    End SyncLock
End Sub

Question piège

Peut-on accéder librement aux contrôles Windows Forms depuis n'importe quel thread ? Pourquoi/Pourquoi pas ?

Réponse :

Non, l'accès aux contrôles WinForms n'est possible que depuis le thread dans lequel ils ont été créés (généralement le thread principal de l'UI). Toute violation entraîne des erreurs imprévisibles ou des plantages. Pour mettre à jour l'UI depuis un autre thread, on utilise les méthodes Invoke ou BeginInvoke.

Exemple :

If TextBox1.InvokeRequired Then
    TextBox1.Invoke(Sub()
        TextBox1.Text = "Données du thread"
    End Sub)
Else
    TextBox1.Text = "Données du thread"
End If

Exemples d'erreurs réelles dues à la méconnaissance des subtilités du sujet

---

Histoire

Dans une application serveur, aucun mécanisme de synchronisation n'a été utilisé lors de l'accès à des listes partagées. Résultat — des exceptions InvalidOperationException apparaissaient sporadiquement et des "corruptions" de données.

---

Histoire

Dans une application Windows, les contrôles étaient mis à jour depuis un thread de fond via BackgroundWorker. L'application "plantait" parfois sans messages explicites — raison : modification directe de l'UI en dehors d'un accès thread-safe.

---

Histoire

Le programmeur a lancé plusieurs threads, chacun modifiant une variable globale sans SyncLock. Résultat — des conditions de concurrence, des comptages incorrects, des bugs difficiles à cerner et des rapports fréquents d'erreurs.