Modo per creare wrapper asincrono

Question

Come creare un wrapper asincrono per il metodo sincrono?

// sync method 
public void LongOperation() 
{ 
    //code... 
} 


// versions of wrapper 
public async Task LongOpertionWrapperAsyncV1() 
{ 
    var task = Task.Factory.StartNew(LongOperation); 
    await task.ConfigureAwait(false); 
} 

public Task LongOpertionWrapperAsyncV2() 
{ 
    var task = Task.Factory.StartNew(LongOperation); 
    task.ConfigureAwait(false); 
    return task; 
} 

Sebbene l'uso di entrambe le versioni non differiscono.

async Task Executor() 
{ 
    await LongOpertionWrapperAsyncV1(); 
    await LongOpertionWrapperAsyncV2(); 
} 

Per i metodi che restituiscono il valore (Task <T>), io uso la prima versione.

Ma mi piacerebbe sapere la vostra opinione.

E c'è una differenza generale tra queste versioni?

Answer 1

Si dovrebbe usare "qualcosa come" V2:

public Task LongOpertionWrapperAsyncV2() 
{ 
    return Task.Run(LongOperation); 
} 

e

async Task Executor() 
{ 
    await LongOpertionWrapperAsyncV2().ConfigureAwait(false); 
} 

Ciò consente di risparmiare un contesto-switch rispetto a V1. Finché non è necessario "attendere un'altra operazione" e l'attività asincrona è l'ultima operazione del metodo, è sufficiente restituire l'attività anziché attendere e lasciare l'attesa al chiamante (che può anche o non può aggiungere ConfigureAwait).

Task.Factory.StartNew è necessario solo se si desidera fornire TaskCreationOptions.LongRunning come suggerito HPT.

UPDATE:
Come Stephen già meantioned: ci sono pochissimi casi in cui si dovrebbe fare async over sync (ma ce ne sono). Quindi pensa a cosa stai facendo esattamente prima di implementare qualcosa di simile. Semplificato detto: Se è un lavoro legato alla CPU NON farlo, se è una sorta di "attesa di IO" FORSE farlo.
Abbiamo un caso qui in cui abbiamo sviluppato una libreria "quasi asincrono tutto il modo", che consiste nel controllare diversi dispositivi HW. C'è tutta la "libreria generico" è asincrona, ma alcuni dei driver di periferica di basso livello e/o librerie di accesso non supportano async così al livello molto più basso che facciamo qualcosa di simile:

public async Task<byte[]> ReadAsync(int length) 
{ 
    return Task.Run(() => hwDevice.Read(length)); 
} 

Il hwDevice.Read fa ancora bloccare il thread, ma non la CPU, quindi l'interfaccia utente è reattiva in quel momento stiamo aspettando l'I/O (nel "live reale" ci sono anche alcune regole di cancellazione e gestione degli errori attorno ad esso).

Answer 2

Neither solution is correct. La migliore risposta è non esporre metodi asincroni per il codice sincrono. Vado più nel "perché" on my blog.

Se il codice è asincrono, utilizzare async e await. Se non lo è, allora non farlo. Dovrebbe essere al chiamante il modo in cui desiderano richiamare il codice (ad esempio, utilizzando Task.Run).