Risposta

In VB.NET, per la multithreading sono disponibili i seguenti meccanismi:

• Classe Thread (System.Threading.Thread) — creazione e avvio manuale dei thread. Richiede una gestione dettagliata, adatta per scenari semplici.
• Classe BackgroundWorker — comoda per operazioni asincrone nelle applicazioni Windows Forms (l'interfaccia rimane reattiva).
• Namespace Task Parallel Library (TPL), inclusi le classi Task e la parola chiave Async/Await. Approccio moderno e raccomandato.

Sincronizzazione:

• Monitor (SyncLock), mutex, semafori — per proteggere le sezioni critiche e accedere alle risorse condivise.

Esempio:

' Avvio di un'attività parallela
Imports System.Threading.Tasks

Sub StartJob()
    Task.Run(Sub()
        ' Operazione lunga
        Console.WriteLine("Lavorando in un thread separato")
    End Sub)
End Sub

' Utilizzo di SyncLock per la sincronizzazione
Dim locker As New Object()

Sub SafeIncrement()
    SyncLock locker
        ' Codice qui eseguito in modo atomico
    End SyncLock
End Sub

Domanda trabocchetto

È possibile accedere liberamente agli elementi di controllo di Windows Forms da qualsiasi thread? Perché/sì o no?

Risposta:

No, l'accesso agli elementi di controllo di WinForms è possibile solo dal thread in cui sono stati creati (di solito il thread principale dell'UI). Violare questo porta a errori o crash imprevedibili. Per aggiornare l'UI da un altro thread si utilizzano i metodi Invoke o BeginInvoke.

Esempio:

If TextBox1.InvokeRequired Then
    TextBox1.Invoke(Sub()
        TextBox1.Text = "Dati dal thread"
    End Sub)
Else
    TextBox1.Text = "Dati dal thread"
End If

Esempi di errori reali a causa della scarsa comprensione dell'argomento

---

Storia

Nell'applicazione server non sono stati utilizzati meccanismi di sincronizzazione lavorando con liste condivise. Risultato — eccezioni InvalidOperationException e "collasso" dei dati.

---

Storia

Nell'applicazione Windows, gli elementi di controllo venivano aggiornati da un thread in background tramite BackgroundWorker. L'applicazione a volte "si bloccava" senza messaggi evidenti — causa: modifica diretta dell'UI al di fuori dell'accesso thread-safe.

---

Storia

Un programmatore ha avviato più thread, ognuno dei quali cambiava una variabile globale senza SyncLock. Risultato — condizioni di gara, risultati di calcoli errati, bug difficili da individuare e frequenti interruzioni della reportistica.