Le chiamate a esecuzione prolungata sono così semplici?

Question

Ho appena, per una bozza di massima, convertito un intero lotto di metodi di accesso ai dati in async usando il seguente schema, e sembra troppo semplice per essere sufficiente per le iterazioni successive. Quanto è sicuro, cosa manca e come dovrei farlo?

Il servizio che fornisce le chiamate di lunga durata:

private class UserService 
{ 
    public IdentityUser GetById(int id) 
    { 
     ... 
    } 
} 

private UserService _userService = new UserService(); 

Il metodo sincrono originale:

public IdentityUser GetById(int id) 
{ 
    return _userService.GetById(id); 
} 

mio fantastico nuovo metodo asincrono:

public async Task<IdentityUser> GetByIdAsync(int id) 
{ 
    await Task.Run(() => _userService.GetById(id)); 
} 

Answer 1

Si consiglia di non fare " falso async "metodi come questo:

Il motivo per cui lo chiamo "falso asincrono" è perché non c'è nulla di intrinsecamente asincrono sull'operazione. In questo caso, dovresti avere solo il metodo sincrono. Se un chiamante vuole renderlo asincrono usando Task.Run, può farlo.

Quando è qualcosa di intrinsecamente asincrono? Quando si effettua una richiesta a un servizio Web oa un database, ad esempio, tra l'invio della richiesta e la ricezione della risposta vi è un periodo di attesa: la richiesta è un'operazione intrinsecamente asincrona. Per evitare di bloccare il thread chiamante, utilizzare async-await.

Answer 2

Tecnicamente, che funziona, ma funziona creando un nuovo thread per eseguire un'operazione sincrona, che a sua volta è avvolgente e blocco su un un'operazione intrinsecamente asincrona. Ciò significa che non stai ottenendo alcuni dei maggiori vantaggi di andare async in primo luogo.

Il modo corretto è procedere in modo asincrono fino in fondo. Mentre in questo momento, probabilmente avete qualcosa di simile:

private class UserService 
{ 
    public IdentityUser GetById(int id) 
    { 
     return mContext.Users.Single(u => u.Id == id); 
    } 
} 

... si dovrebbe ora creare una versione asincrona:

private class UserService 
{ 
    public async Task<IdentityUser> GetByIdAsync(int id) 
    { 
     return await mContext.Users.SingleAsync(u => u.Id == id); 
    } 
} 

Usage:

public async Task<IdentityUser> GetByIdAsync(int id) 
{ 
    return await _userService.GetByIdAsync(id); 
} 

Supponendo, naturalmente, che il tuo framework sottostante supporta metodi asincroni come SingleAsync() per operazioni intrinsecamente asincrone, questo consentirà al sistema di rilasciare il thread corrente mentre aspetti i databas e operazione da completare. Il thread può essere riutilizzato altrove, e quando l'operazione è terminata, puoi usare qualunque thread sia disponibile in quel momento.

Probabilmente vale anche la pena leggere e adottare these Best Practices. Probabilmente vorrai utilizzare .ConfigureAwait(false) ovunque tu non stia accedendo a informazioni contestuali come sessioni e richieste, per esempio.

Questa risposta presuppone, naturalmente, che GetById sia intrinsecamente asincrono: lo si sta recuperando da un disco rigido o da un percorso di rete o qualcosa del genere. Se sta calcolando l'ID dell'utente utilizzando un'operazione CPU a esecuzione prolungata, quindi Task.Run() è un buon modo per andare, e probabilmente vorrai specificare ulteriormente che si tratta di un'attività a esecuzione prolungata negli argomenti a Task.Run().

Answer 3

Task.Run() deve essere utilizzato solo per il lavoro con CPU. Non ricordo bene perché, però. Provare a creare invece un metodo GetByIdAsync() che alla fine chiama una risorsa asincrona.