Usa caso per async / attendi?

Lascio abbastanza bene da solo. C'è un tempo e un luogo per il codice sequenziale e sembra che tu abbia un esempio da manuale.

Async / await sono strumenti utili, ma non gli strumenti giusti per il problema che stai risolvendo.

Metti questo in un altro modo, quale codice sarebbe più facile da mantenere - il tuo codice o codice attuale è stato ristrutturato per usare async / await?

Async / await è solo zucchero sintattico per l'utilizzo di Google Task. Infatti, async / await rende il codice in grado di essere più procedurale piuttosto che rimanere intrappolato nel callback pit. Ad esempio, un (non eccezionale) modo di eseguire un'attività dopo un'altra attività sarebbe:

var task = StartSomething();
var continuation = task.ContinueWith(t => {
    var task2 = StartSomethingElse(t.Result);
    var continueSomethingElse = task2.ContinueWith(t2 => {
        var result2 = r2.result;
        ... // and so forth
    });
});

Quale potrebbe essere semplificato con le attese in questo modo:

// not precisely the same as above due to scoping, but...
var result1 = await StartSomething();
var result2 = await StartSomethingElse(result1);

Ma per async / attendi di salvarti qualcosa, i tuoi passi individuali dovrebbero essere asincroni. Se hai solo un'attività globale (come sembra), async / await non ti salverà nulla.

Per rispondere all'altra dimensione della tua domanda, async / await potrebbe essere o non essere adatto per uno stile basato su eventi, a seconda del resto della tua app. La regola generale è che se usi async / await, dovresti usarlo da cima a fondo. Chiamando .Wait() o .Result sull'attività da un metodo asincrono può risultare in un deadlock .

La logica descritta nella domanda non suona come una macchina a stati tanto quanto un lavoratore in background cancellabile. Una macchina a stati di solito definisce tutti gli stati e le operazioni e quali operazioni sono valide in quale stato e lo stato dei risultati di qualsiasi operazione valida su uno stato.

Sembra che un lavoratore in background sia appropriato per il tuo caso d'uso dichiarato.

Immaginiamo che dopo aver eseguito ciascun test, sia necessario analizzare alcuni dati registrati e scrivere quei risultati, e dire che l'analisi è un'operazione piuttosto dispendiosa dal punto di vista computazionale e non può essere avviata finché tutti i dati non vengono raccolti, mentre la configurazione dell'hardware e la registrazione dei dati sono a buon mercato ma c'è molta attesa.

Potrebbe quindi avere senso usare async e attendere la programmazione di stile per una situazione del genere.

Mentre il software sta preparando l'attrezzatura per il test B, e potresti iniziare l'elaborazione dei dati di A su un altro thread. Avresti un metodo async per farlo, che fornisce i risultati calcolati. Occasionalmente, l'impostazione del test B potrebbe richiedere alcuni risultati dall'analisi, e ci sarebbe await di quei risultati. Se i risultati sono già stati effettuati, l'attesa è quasi istantanea e, in caso contrario, si bloccherà, mantenendo la procedura di test in ordine.

Invece di usare async / await, puoi scrivere il tuo codice di threading e le tue routine di sincronizzazione per far funzionare tutto senza problemi, tuttavia può essere sorprendentemente difficile da ottenere.

Gli sviluppatori di C # hanno progettato async / attendono di riflettere gli scenari di multithreading più comuni in modo da non doversi preoccupare di queste cose. La parola chiave wait attesta fondamentalmente il momento in cui hai bisogno di alcuni risultati importanti dall'operazione in background, e il compilatore può capire cosa può essere in esecuzione in un dato momento.