Scrivere un'API asincrona/non asincrona ben progettata

Question

Sono di fronte al problema della progettazione di metodi che eseguono l'I/O di rete (per una libreria riutilizzabile). Ho letto questa domanda

c# 5 await/async pattern in API design

e anche altri quelli più vicino al mio problema.

Quindi, la domanda è, se voglio fornire asincrono e non asincrono metodo come devo progettare questi?

Ad esempio, per esporre una versione non asincrona di un metodo, ho bisogno di fare qualcosa di simile

public void DoSomething() { 
    DoSomethingAsync(CancellationToken.None).Wait(); 
} 

e mi sento che non è un grande disegno. Vorrei un suggerimento (ad esempio) su come definire metodi privati ​​che possono essere inclusi in quelli pubblici per fornire entrambe le versioni.

Answer 1

Se si desidera l'opzione più gestibile, fornire solo un'API async, che viene implementata senza effettuare alcuna chiamata di blocco o utilizzando alcun thread di thread.

Se si desidera avere entrambe le API async e sincrone, si verificherà un problema di manutenibilità. Hai davvero bisogno di implementarlo due volte: una volta async e una volta sincrono. Entrambi i metodi sembreranno quasi identici, quindi l'implementazione iniziale è semplice, ma si finirà con due metodi quasi identici separati, quindi la manutenzione è problematica.

In particolare, non esiste un modo semplice e buono per creare semplicemente un "wrapper" async o sincrono. Stephen Toub ha le migliori informazioni sul tema:

1. Should I expose asynchronous wrappers for synchronous methods?
2. Should I expose synchronous wrappers for asynchronous methods?

(breve risposta ad entrambe le domande è "no")

Answer 2

Sono d'accordo sia con Marc e Stephen (Cleary).

(A proposito, ho iniziato a scrivere questo come commento alla risposta di Stephen, ma si è rivelato troppo lungo: fatemi sapere se è OK scrivere come risposta o no, e sentitevi liberi di prendere le cose da esso e aggiungilo alla risposta di Stephen, nello spirito di "fornire la migliore risposta").

In realtà "dipende": come ha detto Marc, è importante sapere come DoSomethingAsync è asincrono. Siamo tutti d'accordo che non ha senso avere il metodo "sync" chiama il metodo "async" e "wait": questo può essere fatto nel codice utente. L'unico vantaggio di avere un metodo separato è quello di ottenere guadagni di prestazioni effettive, di avere un'implementazione che è, sotto la cappa, diversa e adattata allo scenario sincrono. Questo è particolarmente vero se il metodo "asincrono" sta creando un thread (o lo prende da un threadpool): si finisce con qualcosa che sotto utilizza due "control flow", mentre "promising" con i suoi look sincroni da eseguire nel contesto dei chiamanti. Questo potrebbe anche avere problemi di concorrenza, a seconda dell'implementazione.

Anche in altri casi, come l'I/O intensivo menzionato dall'OP, può valere la pena di avere due diverse implementazioni.La maggior parte dei sistemi operativi (Windows di sicuro) hanno meccanismi I/O diversi su misura per i due scenari: ad esempio, l'esecuzione asincrona e l'operazione I/O trae grandi vantaggi dai meccanismi del livello OS come le porte di completamento I/O, che aggiungono un po ' overhead (non significativo, ma non nullo) nel kernel (dopotutto, devono fare contabilità, distribuzione, ecc.) e un'implementazione più diretta per le operazioni sincrone. La complessità del codice varia molto, specialmente nelle funzioni in cui vengono eseguite/coordinate più operazioni.

Cosa farei è:

• hanno alcuni esempi/prova per utilizzo tipico e scenari
• vedere quale variante API utilizzata, dove e misura. Misura anche la differenza di prestazioni tra una variante "sincro puro" e "sincronizzazione". (non per l'intera API, ma per alcuni casi tipici selezionati)
• in base alla misurazione, decidere se vale il costo aggiunto.

Questo principalmente perché due obiettivi sono in qualche modo in contrasto l'uno con l'altro. Se si desidera un codice gestibile, la scelta più ovvia è implementare la sincronizzazione in termini di asincrono/attesa (o viceversa) (o, meglio ancora, fornire solo la variante asincrona e lasciare che l'utente "attenda"); se vuoi prestazioni devi implementare le due funzioni in modo diverso, per sfruttare diversi meccanismi sottostanti (dal framework o dal sistema operativo). Penso che non dovrebbe fare la differenza da un punto di vista del test unitario su come implementare effettivamente la tua API.