Se la mia interfaccia deve restituire Task, qual è il modo migliore per avere un'implementazione senza operazioni?

Nel codice seguente, a causa dell'interfaccia, la classe LazyBardeve restituire un'attività dal suo metodo (e per ragioni di amore non può essere modificata). Se l' LazyBarimplementazione è insolita in quanto accade che venga eseguita rapidamente e in modo sincrono, qual è il modo migliore per restituire un'attività senza operazioni dal metodo?

Sono andato di Task.Delay(0)seguito, tuttavia vorrei sapere se questo ha effetti collaterali sulle prestazioni se la funzione è chiamata molto (per amor di argomenti, diciamo centinaia di volte al secondo):

• Questo zucchero sintattico si scioglie in qualcosa di grosso?
• Inizia a ostruire il pool di thread della mia applicazione?
• La mannaia del compilatore è abbastanza per gestire Delay(0)diversamente?
• Sarebbe return Task.Run(() => { });diverso?

Esiste un modo migliore?

using System.Threading.Tasks;

namespace MyAsyncTest
{
    internal interface IFooFace
    {
        Task WillBeLongRunningAsyncInTheMajorityOfImplementations();
    }

    /// <summary>
    /// An implementation, that unlike most cases, will not have a long-running
    /// operation in 'WillBeLongRunningAsyncInTheMajorityOfImplementations'
    /// </summary>
    internal class LazyBar : IFooFace
    {
        #region IFooFace Members

        public Task WillBeLongRunningAsyncInTheMajorityOfImplementations()
        {
            // First, do something really quick
            var x = 1;

            // Can't return 'null' here! Does 'Task.Delay(0)' have any performance considerations?
            // Is it a real no-op, or if I call this a lot, will it adversely affect the
            // underlying thread-pool? Better way?
            return Task.Delay(0);

            // Any different?
            // return Task.Run(() => { });

            // If my task returned something, I would do:
            // return Task.FromResult<int>(12345);
        }

        #endregion
    }

    internal class Program
    {
        private static void Main(string[] args)
        {
            Test();
        }

        private static async void Test()
        {
            IFooFace foo = FactoryCreate();
            await foo.WillBeLongRunningAsyncInTheMajorityOfImplementations();
            return;
        }

        private static IFooFace FactoryCreate()
        {
            return new LazyBar();
        }
    }
}

L'uso Task.FromResult(0)o Task.FromResult<object>(null)comporta un sovraccarico minore rispetto alla creazione di un Taskcon un'espressione no-op. Quando si crea un Taskcon un risultato predeterminato, non sono previsti costi generali di pianificazione.

Oggi, consiglierei di utilizzare Task.CompletedTask per raggiungere questo obiettivo.

Per aggiungere alla risposta di Reed Copsey sull'utilizzo Task.FromResult, è possibile migliorare ulteriormente le prestazioni se si memorizza nella cache l'attività già completata poiché tutte le istanze delle attività completate sono uguali:

public static class TaskExtensions
{
    public static readonly Task CompletedTask = Task.FromResult(false);
}

Con TaskExtensions.CompletedTaskte puoi usare la stessa istanza in tutto il dominio dell'app.

L' ultima versione di .Net Framework (v4.6) aggiunge proprio questo con la Task.CompletedTaskproprietà statica

Task completedTask = Task.CompletedTask;

Task.Delay(0)come nella risposta accettata è stato un buon approccio, in quanto è una copia cache di un completato Task.

A partire da 4.6 c'è ora Task.CompletedTaskche è più esplicito nel suo scopo, ma non solo Task.Delay(0)restituisce ancora una singola istanza memorizzata nella cache, ma restituisce la stessa singola istanza memorizzata nella cache Task.CompletedTask.

La natura cache di nessuno dei due è garantita per rimanere costante, ma come ottimizzazioni dipendenti dall'implementazione che dipendono solo dall'implementazione come ottimizzazioni (ovvero, funzionerebbero comunque correttamente se l'implementazione fosse cambiata in qualcosa che era ancora valido) l'uso di Task.Delay(0)era meglio della risposta accettata.

Recentemente riscontrato questo e continuato a ricevere avvisi / errori sul metodo che è nullo.

Ci occupiamo di placare il compilatore e questo chiarisce:

    public async Task MyVoidAsyncMethod()
    {
        await Task.CompletedTask;
    }

Questo riunisce il meglio di tutti i consigli qui finora. Non è necessaria alcuna dichiarazione di ritorno a meno che tu non stia effettivamente facendo qualcosa nel metodo.

return Task.CompletedTask; // this will make the compiler happy

Quando è necessario restituire il tipo specificato:

Task.FromResult<MyClass>(null);

Preferisco la Task completedTask = Task.CompletedTask;soluzione di .Net 4.6, ma un altro approccio è quello di contrassegnare il metodo asincrono e restituire il vuoto:

    public async Task WillBeLongRunningAsyncInTheMajorityOfImplementations()
    {
    }

Riceverai un avviso (CS1998 - Funzione asincrona senza attendere l'espressione), ma è sicuro ignorarlo in questo contesto.

Se stai usando generici, tutte le risposte ci daranno un errore di compilazione. È possibile utilizzare return default(T);. Esempio sotto per spiegare ulteriormente.

public async Task<T> GetItemAsync<T>(string id)
            {
                try
                {
                    var response = await this._container.ReadItemAsync<T>(id, new PartitionKey(id));
                    return response.Resource;
                }
                catch (CosmosException ex) when (ex.StatusCode == System.Net.HttpStatusCode.NotFound)
                {

                    return default(T);
                }

            }

return await Task.FromResult(new MyClass());