Antwoord

In VB.NET zijn de volgende mechanismen beschikbaar voor multithreading:

• Klasse Thread (System.Threading.Thread) — handmatige creatie en uitvoering van threads. Vereist gedetailleerd beheer, geschikt voor eenvoudige scenario's.
• Klasse BackgroundWorker — handig voor asynchrone operaties in Windows Forms-applicaties (UI blijft responsief).
• Namespace Task Parallel Library (TPL), inclusief de klassen Task en het trefwoord Async/Await. Een moderne en aanbevolen aanpak.

Synchronisatie:

• Monitoren (SyncLock), mutexen, semaforen — ter bescherming van kritieke secties en toegang tot gedeelde bronnen.

Voorbeeld:

' Start een parallelle taak
Imports System.Threading.Tasks

Sub StartJob()
    Task.Run(Sub()
        ' Langdurige operatie
        Console.WriteLine("Werken in een aparte thread")
    End Sub)
End Sub

' Gebruik SyncLock voor synchronisatie
Dim locker As New Object()

Sub SafeIncrement()
    SyncLock locker
        ' Code hier wordt atomair uitgevoerd
    End SyncLock
End Sub

Vraag met een addertje onder het gras

Mag je vrij de Windows Forms-besturingselementen benaderen vanuit elke thread? Waarom/waarom niet?

Antwoord:

Nee, toegang tot WinForms-besturingselementen is alleen mogelijk vanuit de thread waarin ze zijn gemaakt (meestal de hoofd UI-thread). Het overtreden hiervan leidt tot onvoorspelbare fouten of crashes. Voor het bijwerken van de UI vanuit een andere thread gebruik je de methoden Invoke of BeginInvoke.

Voorbeeld:

If TextBox1.InvokeRequired Then
    TextBox1.Invoke(Sub()
        TextBox1.Text = "Gegevens uit de thread"
    End Sub)
Else
    TextBox1.Text = "Gegevens uit de thread"
End If

Voorbeelden van echte fouten door gebrek aan kennis over de nuances van het onderwerp

---

Verhaal

In de serverapplicatie werden geen synchronisatiemechanismen gebruikt bij het werken met gedeelde lijsten. Dit resulteerde in sporadische InvalidOperationException-excepties en "corruptie" van gegevens.

---

Verhaal

In de Windows-applicatie werden besturingselementen bijgewerkt vanuit een achtergrond thread via BackgroundWorker. De applicatie viel soms "uit" zonder duidelijke berichten — reden: directe wijziging van de UI buiten veilige toegang.

---

Verhaal

Een programmeur startte verschillende threads, waarvan er elke een globale variabele wijzigde zonder SyncLock. Resultaat — race conditions, onjuiste berekeningen, moeilijk te traceren bugs en frequente rapportage fouten.