Come eseguire un metodo Task <T> asincrono in modo sincrono?

Sto imparando su asincrono / attendo e mi sono imbattuto in una situazione in cui ho bisogno di chiamare un metodo asincrono in modo sincrono. Come lo posso fare?

Metodo asincrono:

public async Task<Customers> GetCustomers()
{
    return await Service.GetCustomersAsync();
}

Uso normale:

public async void GetCustomers()
{
    customerList = await GetCustomers();
}

Ho provato a utilizzare quanto segue:

Task<Customer> task = GetCustomers();
task.Wait()

Task<Customer> task = GetCustomers();
task.RunSynchronously();

Task<Customer> task = GetCustomers();
while(task.Status != TaskStatus.RanToCompletion)

Ho anche provato un suggerimento da qui , tuttavia non funziona quando il dispatcher è in uno stato sospeso.

public static void WaitWithPumping(this Task task) 
{
        if (task == null) throw new ArgumentNullException(“task”);
        var nestedFrame = new DispatcherFrame();
        task.ContinueWith(_ => nestedFrame.Continue = false);
        Dispatcher.PushFrame(nestedFrame);
        task.Wait();
}

Ecco l'eccezione e la traccia dello stack dalla chiamata RunSynchronously:

System.InvalidOperationException

Messaggio : RunSynchronously non può essere chiamato su un'attività non associata a un delegato.

InnerException : null

Fonte : mscorlib

StackTrace :

          at System.Threading.Tasks.Task.InternalRunSynchronously(TaskScheduler scheduler)
   at System.Threading.Tasks.Task.RunSynchronously()
   at MyApplication.CustomControls.Controls.MyCustomControl.CreateAvailablePanelList() in C:\Documents and Settings\...\MyApplication.CustomControls\Controls\MyCustomControl.xaml.cs:line 638
   at MyApplication.CustomControls.Controls.MyCustomControl.get_AvailablePanels() in C:\Documents and Settings\...\MyApplication.CustomControls\Controls\MyCustomControl.xaml.cs:line 233
   at MyApplication.CustomControls.Controls.MyCustomControl.<CreateOpenPanelList>b__36(DesktopPanel panel) in C:\Documents and Settings\...\MyApplication.CustomControls\Controls\MyCustomControl.xaml.cs:line 597
   at System.Collections.Generic.List`1.ForEach(Action`1 action)
   at MyApplication.CustomControls.Controls.MyCustomControl.<CreateOpenPanelList>d__3b.MoveNext() in C:\Documents and Settings\...\MyApplication.CustomControls\Controls\MyCustomControl.xaml.cs:line 625
   at System.Runtime.CompilerServices.TaskAwaiter.<>c__DisplayClass7.<TrySetContinuationForAwait>b__1(Object state)
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
   at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler)
   at System.Windows.Threading.DispatcherOperation.InvokeImpl()
   at System.Windows.Threading.DispatcherOperation.InvokeInSecurityContext(Object state)
   at System.Threading.ExecutionContext.runTryCode(Object userData)
   at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Windows.Threading.DispatcherOperation.Invoke()
   at System.Windows.Threading.Dispatcher.ProcessQueue()
   at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
   at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler)
   at System.Windows.Threading.Dispatcher.InvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs)
   at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
   at MS.Win32.UnsafeNativeMethods.DispatchMessage(MSG& msg)
   at System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame frame)
   at System.Windows.Threading.Dispatcher.PushFrame(DispatcherFrame frame)
   at System.Windows.Threading.Dispatcher.Run()
   at System.Windows.Application.RunDispatcher(Object ignore)
   at System.Windows.Application.RunInternal(Window window)
   at System.Windows.Application.Run(Window window)
   at System.Windows.Application.Run()
   at MyApplication.App.Main() in C:\Documents and Settings\...\MyApplication\obj\Debug\App.g.cs:line 50
   at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args)
   at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
   at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
   at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.ThreadHelper.ThreadStart()

Ecco una soluzione alternativa che ho scoperto che funziona per tutti i casi (inclusi i dispatcher sospesi). Non è il mio codice e sto ancora lavorando per comprenderlo appieno, ma funziona.

Può essere chiamato usando:

customerList = AsyncHelpers.RunSync<List<Customer>>(() => GetCustomers());

Il codice è di qui

public static class AsyncHelpers
{
    /// <summary>
    /// Execute's an async Task<T> method which has a void return value synchronously
    /// </summary>
    /// <param name="task">Task<T> method to execute</param>
    public static void RunSync(Func<Task> task)
    {
        var oldContext = SynchronizationContext.Current;
        var synch = new ExclusiveSynchronizationContext();
        SynchronizationContext.SetSynchronizationContext(synch);
        synch.Post(async _ =>
        {
            try
            {
                await task();
            }
            catch (Exception e)
            {
                synch.InnerException = e;
                throw;
            }
            finally
            {
                synch.EndMessageLoop();
            }
        }, null);
        synch.BeginMessageLoop();

        SynchronizationContext.SetSynchronizationContext(oldContext);
    }

    /// <summary>
    /// Execute's an async Task<T> method which has a T return type synchronously
    /// </summary>
    /// <typeparam name="T">Return Type</typeparam>
    /// <param name="task">Task<T> method to execute</param>
    /// <returns></returns>
    public static T RunSync<T>(Func<Task<T>> task)
    {
        var oldContext = SynchronizationContext.Current;
        var synch = new ExclusiveSynchronizationContext();
        SynchronizationContext.SetSynchronizationContext(synch);
        T ret = default(T);
        synch.Post(async _ =>
        {
            try
            {
                ret = await task();
            }
            catch (Exception e)
            {
                synch.InnerException = e;
                throw;
            }
            finally
            {
                synch.EndMessageLoop();
            }
        }, null);
        synch.BeginMessageLoop();
        SynchronizationContext.SetSynchronizationContext(oldContext);
        return ret;
    }

    private class ExclusiveSynchronizationContext : SynchronizationContext
    {
        private bool done;
        public Exception InnerException { get; set; }
        readonly AutoResetEvent workItemsWaiting = new AutoResetEvent(false);
        readonly Queue<Tuple<SendOrPostCallback, object>> items =
            new Queue<Tuple<SendOrPostCallback, object>>();

        public override void Send(SendOrPostCallback d, object state)
        {
            throw new NotSupportedException("We cannot send to our same thread");
        }

        public override void Post(SendOrPostCallback d, object state)
        {
            lock (items)
            {
                items.Enqueue(Tuple.Create(d, state));
            }
            workItemsWaiting.Set();
        }

        public void EndMessageLoop()
        {
            Post(_ => done = true, null);
        }

        public void BeginMessageLoop()
        {
            while (!done)
            {
                Tuple<SendOrPostCallback, object> task = null;
                lock (items)
                {
                    if (items.Count > 0)
                    {
                        task = items.Dequeue();
                    }
                }
                if (task != null)
                {
                    task.Item1(task.Item2);
                    if (InnerException != null) // the method threw an exeption
                    {
                        throw new AggregateException("AsyncHelpers.Run method threw an exception.", InnerException);
                    }
                }
                else
                {
                    workItemsWaiting.WaitOne();
                }
            }
        }

        public override SynchronizationContext CreateCopy()
        {
            return this;
        }
    }
}

Tieni presente che questa risposta ha tre anni. L'ho scritto basandomi principalmente su un'esperienza con .Net 4.0 e molto poco con 4.5 specialmente con async-await. In generale è una bella soluzione semplice, ma a volte rompe le cose. Si prega di leggere la discussione nei commenti.

.Net 4.5

Usa questo:

// For Task<T>: will block until the task is completed...
var result = task.Result; 

// For Task (not Task<T>): will block until the task is completed...
task2.RunSynchronously();

Vedi: TaskAwaiter , Task.Result , Task.RunSincronicamente

.Net 4.0

Usa questo:

var x = (IAsyncResult)task;
task.Start();

x.AsyncWaitHandle.WaitOne();

...o questo:

task.Start();
task.Wait();

Sorpreso nessuno ha menzionato questo:

public Task<int> BlahAsync()
{
    // ...
}

int result = BlahAsync().GetAwaiter().GetResult();

Non carino come alcuni degli altri metodi qui, ma ha i seguenti vantaggi:

• non ingoia eccezioni (come Wait)
• non avvolgerà alcuna eccezione generata in un AggregateException(mi piace Result)
• funziona per entrambi Taske Task<T>( provalo tu stesso! )

Inoltre, poiché GetAwaiterè tipizzato in anatra, questo dovrebbe funzionare per qualsiasi oggetto che viene restituito da un metodo asincrono (come ConfiguredAwaitableo YieldAwaitable), non solo Attività.

modifica: Si noti che è possibile per questo approccio (o utilizzo .Result) il deadlock, a meno che non si assicuri di aggiungere .ConfigureAwait(false)ogni volta che si attende, per tutti i metodi asincroni che possono essere raggiunti da BlahAsync()(non solo quelli che chiama direttamente). Spiegazione .

// In BlahAsync() body
await FooAsync(); // BAD!
await FooAsync().ConfigureAwait(false); // Good... but make sure FooAsync() and
                                        // all its descendants use ConfigureAwait(false)
                                        // too. Then you can be sure that
                                        // BlahAsync().GetAwaiter().GetResult()
                                        // won't deadlock.

Se sei troppo pigro per aggiungere .ConfigureAwait(false)ovunque e non ti importa delle prestazioni, puoi farlo in alternativa

Task.Run(() => BlahAsync()).GetAwaiter().GetResult()

È molto più semplice eseguire l'attività sul pool di thread, piuttosto che tentare di ingannare lo scheduler per eseguirlo in modo sincrono. In questo modo puoi essere sicuro che non si bloccherà. Le prestazioni sono influenzate a causa del cambio di contesto.

Task<MyResult> DoSomethingAsync() { ... }

// Starts the asynchronous task on a thread-pool thread.
// Returns a proxy to the original task.
Task<MyResult> task = Task.Run(() => DoSomethingAsync());

// Will block until the task is completed...
MyResult result = task.Result; 

Sto imparando su asincrono / attendo e mi sono imbattuto in una situazione in cui ho bisogno di chiamare un metodo asincrono in modo sincrono. Come lo posso fare?

La risposta migliore è che non lo fai , con i dettagli che dipendono da quale sia la "situazione".

È un getter / setter di proprietà? Nella maggior parte dei casi, è meglio disporre di metodi asincroni rispetto alle "proprietà asincrone". (Per maggiori informazioni, vedi il mio post sul blog sulle proprietà asincrone ).

Si tratta di un'app MVVM e si desidera eseguire l'associazione dati asincrona? Quindi utilizzare qualcosa come il mio NotifyTask, come descritto nel mio articolo MSDN sull'associazione di dati asincroni .

È un costruttore? Quindi probabilmente vorrai considerare un metodo di fabbrica asincrono. (Per maggiori informazioni, vedi il mio post sul blog sui costruttori asincroni ).

C'è quasi sempre una risposta migliore che fare sync-over-async.

Se non è possibile per la tua situazione (e lo sai facendo una domanda qui descrive la situazione ), allora ti consiglio di usare solo il codice sincrono. Async fino in fondo è il migliore; la sincronizzazione fino in fondo è la seconda migliore. La sincronizzazione su asincrono non è consigliata.

Tuttavia, ci sono alcune situazioni in cui è necessario il sync-over-async. In particolare, sei vincolato dal codice chiamante in modo da dover essere sincronizzato (e non hai assolutamente modo di ripensare o riformulare il tuo codice per consentire l'asincronia), e tu hanno a chiamata asincrona del codice. Questo è un situazione molto rara, ma di tanto in tanto si presenta.

In tal caso, dovrai utilizzare uno degli hack descritti nel mio articolo su async sviluppo brownfield , in particolare:

• Blocco (ad es. GetAwaiter().GetResult() .). Si noti che ciò può causare deadlock (come descrivo sul mio blog).
• Esecuzione del codice su un thread del pool di thread (ad esempio, Task.Run(..).GetAwaiter().GetResult() ). Si noti che questo funzionerà solo se il codice asincrono può essere eseguito su un thread del pool di thread (ovvero, non dipende da un contesto UI o ASP.NET).
• Cicli di messaggi nidificati. Si noti che questo funzionerà solo se il codice asincrono assume solo un contesto a thread singolo, non un tipo di contesto specifico (molti UI e codice ASP.NET prevedono un contesto specifico).

I loop di messaggi nidificati sono i più pericolosi di tutti gli hack, perché causano il rientro . Il rientro è estremamente difficile da ragionare e (IMO) è la causa della maggior parte dei bug delle applicazioni su Windows. In particolare, se ti trovi sul thread dell'interfaccia utente e blocchi su una coda di lavoro (in attesa del completamento del lavoro asincrono), il CLR esegue effettivamente alcuni messaggi di pumping per te - gestirà effettivamente alcuni messaggi Win32 dall'interno del tuo codice . Oh, e non hai idea di quali messaggi - quando Chris Brumme dice "Non sarebbe bello sapere esattamente cosa verrà pompato? Sfortunatamente, pompare è un'arte nera che va oltre la comprensione mortale". , quindi non abbiamo davvero alcuna speranza di saperlo.

Quindi, quando blocchi in questo modo su un thread dell'interfaccia utente, stai chiedendo problemi. Un'altra citazione di cbrumme dallo stesso articolo: "Di tanto in tanto, i clienti all'interno o all'esterno dell'azienda scoprono che stiamo pompando messaggi durante il blocco gestito su un STA [thread dell'interfaccia utente]. Questa è una preoccupazione legittima, perché sanno che è molto difficile per scrivere codice robusto di fronte al rientro ".

Sì. Codice molto difficile da scrivere che è robusto di fronte al rientro. E i cicli di messaggi nidificati ti costringono a scrivere codice robusto rispetto al rientro. Questo è il motivo per cui la risposta accettata (e più votata) a questa domanda è estremamente pericolosa nella pratica.

Se sei completamente fuori da tutte le altre opzioni - non puoi riprogettare il tuo codice, non puoi ristrutturarlo in modo che sia asincrono - sei costretto a sincronizzare il codice chiamante immutabile - non puoi cambiare il codice downstream per essere sincronizzato - non puoi bloccare - non puoi eseguire il codice asincrono su un thread separato - quindi e solo allora dovresti considerare di abbracciare il rientro.

Se ti trovi in ​​questo angolo, ti consiglierei di usare qualcosa come Dispatcher.PushFrameper le app WPF , fare un ciclo con Application.DoEventsper le app WinForm e, per il caso generale, il mio AsyncContext.Run.

Se sto leggendo bene la tua domanda, il codice che desidera la chiamata sincrona a un metodo asincrono viene eseguito su un thread dispatcher sospeso. E vuoi effettivamente bloccare in modo sincrono quel thread fino al completamento del metodo asincrono.

I metodi asincroni in C # 5 sono potenziati tagliando in modo efficace il metodo in pezzi sotto il cofano e restituendo uno Taskche può tracciare il completamento complessivo dell'intero shabang. Tuttavia, il modo in cui vengono eseguiti i metodi troncati può dipendere dal tipo di espressione passato aawait all'operatore.

Il più delle volte, utilizzerai awaitun'espressione di tipo Task. L'implementazione del awaitmodello da parte di Task è "intelligente" in quanto si differenzia da SynchronizationContext, il che provoca sostanzialmente quanto segue:

1. Se il thread entra in await trova su un thread del loop di messaggi Dispatcher o WinForms, garantisce che i blocchi del metodo asincrono si verifichino come parte dell'elaborazione della coda dei messaggi.
2. Se il thread immesso in si awaittrova su un thread del pool di thread, i blocchi rimanenti del metodo asincrono si verificano in qualsiasi punto del pool di thread.

Ecco perché probabilmente stai riscontrando problemi - l'implementazione del metodo asincrono sta cercando di eseguire il resto sul Dispatcher - anche se è sospeso.

.... backup! ....

Devo porre la domanda, perché stai cercando di bloccare in modo sincrono un metodo asincrono? In questo modo si vanificherebbe lo scopo del motivo per cui il metodo voleva essere chiamato in modo asincrono. In generale, quando si inizia a utilizzare awaitun metodo Dispatcher o UI, è necessario rendere asincrono l'intero flusso dell'interfaccia utente. Ad esempio, se il tuo callstack era simile al seguente:

1. [Superiore] WebRequest.GetResponse()
2. YourCode.HelperMethod()
3. YourCode.AnotherMethod()
4. YourCode.EventHandlerMethod()
5. [UI Code].Plumbing()- WPFoppureWinFormsCodice
6. [Message Loop] - WPFo WinFormsMessage Loop

Quindi, una volta che il codice è stato trasformato in asincrono, in genere si finisce con

1. [Superiore] WebRequest.GetResponseAsync()
2. YourCode.HelperMethodAsync()
3. YourCode.AnotherMethodAsync()
4. YourCode.EventHandlerMethodAsync()
5. [UI Code].Plumbing()- WPFo WinFormsCodice
6. [Message Loop] - WPFoppureWinFormsMessage Loop

In realtà rispondendo

La classe AsyncHelpers sopra funziona effettivamente perché si comporta come un ciclo di messaggi nidificato, ma installa il proprio meccanico parallelo sul Dispatcher anziché tentare di eseguirlo sul Dispatcher stesso. Questa è una soluzione alternativa per il tuo problema.

Un'altra soluzione alternativa consiste nell'eseguire il metodo asincrono su un thread di thread pool e quindi attendere il completamento. Farlo è facile: puoi farlo con il seguente frammento:

var customerList = TaskEx.RunEx(GetCustomers).Result;

L'API finale sarà Task.Run (...), ma con il CTP avrai bisogno dei suffissi Ex ( spiegazione qui ).

Questo funziona bene per me

public static class TaskHelper
{
    public static void RunTaskSynchronously(this Task t)
    {
        var task = Task.Run(async () => await t);
        task.Wait();
    }

    public static T RunTaskSynchronously<T>(this Task<T> t)
    {
        T res = default(T);
        var task = Task.Run(async () => res = await t);
        task.Wait();
        return res;
    }
}

Il modo più semplice che ho trovato per eseguire l'attività in modo sincrono e senza bloccare il thread dell'interfaccia utente è utilizzare RunSynchronously () come:

Task t = new Task(() => 
{ 
   //.... YOUR CODE ....
});
t.RunSynchronously();

Nel mio caso, ho un evento che si attiva quando si verifica qualcosa. Non so quante volte accadrà. Quindi, uso il codice sopra nel mio evento, quindi ogni volta che si attiva, crea un'attività. Le attività vengono eseguite in modo sincrono e per me funziona benissimo. Sono rimasto sorpreso dal fatto che mi ci è voluto così tanto tempo per scoprirlo, considerando quanto sia semplice. Di solito, i consigli sono molto più complessi e soggetti a errori. Questo è stato semplice e pulito.

L'ho affrontato un paio di volte, principalmente nei test unitari o nello sviluppo di un servizio Windows. Attualmente utilizzo sempre questa funzione:

        var runSync = Task.Factory.StartNew(new Func<Task>(async () =>
        {
            Trace.WriteLine("Task runSync Start");
            await TaskEx.Delay(2000); // Simulates a method that returns a task and
                                      // inside it is possible that there
                                      // async keywords or anothers tasks
            Trace.WriteLine("Task runSync Completed");
        })).Unwrap();
        Trace.WriteLine("Before runSync Wait");
        runSync.Wait();
        Trace.WriteLine("After runSync Waited");

È semplice, facile e non ho avuto problemi.

Ho trovato questo codice nel componente Microsoft.AspNet.Identity.Core e funziona.

private static readonly TaskFactory _myTaskFactory = new 
     TaskFactory(CancellationToken.None, TaskCreationOptions.None, 
     TaskContinuationOptions.None, TaskScheduler.Default);

// Microsoft.AspNet.Identity.AsyncHelper
public static TResult RunSync<TResult>(Func<Task<TResult>> func)
{
    CultureInfo cultureUi = CultureInfo.CurrentUICulture;
    CultureInfo culture = CultureInfo.CurrentCulture;
    return AsyncHelper._myTaskFactory.StartNew<Task<TResult>>(delegate
    {
        Thread.CurrentThread.CurrentCulture = culture;
        Thread.CurrentThread.CurrentUICulture = cultureUi;
        return func();
    }).Unwrap<TResult>().GetAwaiter().GetResult();
}

Solo una piccola nota: questo approccio:

Task<Customer> task = GetCustomers();
task.Wait()

funziona per WinRT.

Lasciatemi spiegare:

private void TestMethod()
{
    Task<Customer> task = GetCustomers(); // call async method as sync and get task as result
    task.Wait(); // wait executing the method
    var customer = task.Result; // get's result.
    Debug.WriteLine(customer.Name); //print customer name
}
public class Customer
{
    public Customer()
    {
        new ManualResetEvent(false).WaitOne(TimeSpan.FromSeconds(5));//wait 5 second (long term operation)
    }
    public string Name { get; set; }
}
private Task<Customer> GetCustomers()
{
    return Task.Run(() => new Customer
    {
        Name = "MyName"
    });
}

Inoltre, questo approccio funziona solo per le soluzioni di Windows Store!

Nota: in questo modo non è sicuro se si chiama il proprio metodo all'interno di un altro metodo asincrono (secondo i commenti di @Servy)

Nel tuo codice, attendi prima che venga eseguita l'attività ma non l'hai avviata, quindi attende indefinitamente. Prova questo:

Task<Customer> task = GetCustomers();
task.RunSynchronously();

Modificare:

Dici di avere un'eccezione. Pubblica ulteriori dettagli, inclusa la traccia dello stack.
Mono contiene il seguente caso di test:

[Test]
public void ExecuteSynchronouslyTest ()
{
        var val = 0;
        Task t = new Task (() => { Thread.Sleep (100); val = 1; });
        t.RunSynchronously ();

        Assert.AreEqual (1, val);
}

Controlla se questo funziona per te. In caso contrario, anche se molto improbabile, potresti avere una build strana di CTP asincrono. Se funziona, potresti voler esaminare cosa genera esattamente il compilatore e in che modo l' Taskistanza è diversa da questo esempio.

Modifica n. 2:

Ho verificato con Reflector che l'eccezione che hai descritto si verifica quando lo m_actionè null. Questo è un po 'strano, ma non sono un esperto di CTP asincrono. Come ho detto, si dovrebbe decompilare il codice e vedere come esattamente Taskviene istanziato alcun come mai i suoi m_actionIS null.

PS Qual è il problema con i downvotes occasionali? Ti interessa elaborare?

Testato in .Net 4.6. Può anche evitare il deadlock.

Per il ritorno del metodo asincrono Task.

Task DoSomeWork();
Task.Run(async () => await DoSomeWork()).Wait();

Per il ritorno del metodo asincrono Task<T>

Task<T> GetSomeValue();
var result = Task.Run(() => GetSomeValue()).Result;

Modifica :

Se il chiamante è in esecuzione nel thread del pool di thread (o anche il chiamante è in un'attività), in alcuni casi potrebbe comunque causare un deadlock.

usa il codice di seguito riportato

Task.WaitAll(Task.Run(async () => await service.myAsyncMethod()));

Perché non creare una chiamata come:

Service.GetCustomers();

non è asincrono.

Questa risposta è progettata per chiunque stia utilizzando WPF per .NET 4.5.

Se si tenta di eseguire Task.Run()sul thread della GUI, si task.Wait()bloccherà indefinitamente, se non si dispone della asyncparola chiave nella definizione della funzione.

Questo metodo di estensione risolve il problema controllando se siamo sul thread GUI e, in tal caso, eseguendo l'attività sul thread dispatcher WPF.

Questa classe può fungere da collante tra il mondo asincrono / attende e il mondo non asincrono / attende, in situazioni in cui è inevitabile, come le proprietà MVVM o le dipendenze da altre API che non usano asincrono / attendono.

/// <summary>
///     Intent: runs an async/await task synchronously. Designed for use with WPF.
///     Normally, under WPF, if task.Wait() is executed on the GUI thread without async
///     in the function signature, it will hang with a threading deadlock, this class 
///     solves that problem.
/// </summary>
public static class TaskHelper
{
    public static void MyRunTaskSynchronously(this Task task)
    {
        if (MyIfWpfDispatcherThread)
        {
            var result = Dispatcher.CurrentDispatcher.InvokeAsync(async () => { await task; });
            result.Wait();
            if (result.Status != DispatcherOperationStatus.Completed)
            {
                throw new Exception("Error E99213. Task did not run to completion.");
            }
        }
        else
        {
            task.Wait();
            if (task.Status != TaskStatus.RanToCompletion)
            {
                throw new Exception("Error E33213. Task did not run to completion.");
            }
        }
    }

    public static T MyRunTaskSynchronously<T>(this Task<T> task)
    {       
        if (MyIfWpfDispatcherThread)
        {
            T res = default(T);
            var result = Dispatcher.CurrentDispatcher.InvokeAsync(async () => { res = await task; });
            result.Wait();
            if (result.Status != DispatcherOperationStatus.Completed)
            {
                throw new Exception("Error E89213. Task did not run to completion.");
            }
            return res;
        }
        else
        {
            T res = default(T);
            var result = Task.Run(async () => res = await task);
            result.Wait();
            if (result.Status != TaskStatus.RanToCompletion)
            {
                throw new Exception("Error E12823. Task did not run to completion.");
            }
            return res;
        }
    }

    /// <summary>
    ///     If the task is running on the WPF dispatcher thread.
    /// </summary>
    public static bool MyIfWpfDispatcherThread
    {
        get
        {
            return Application.Current.Dispatcher.CheckAccess();
        }
    }
}

Chiamare semplicemente .Result;o .Wait()è un rischio di deadlock come molti hanno detto nei commenti. Dal momento che molti di noi amano gli oneliner, puoi usarli per.Net 4.5<

Acquisizione di un valore tramite un metodo asincrono:

var result = Task.Run(() => asyncGetValue()).Result;

Chiamare in modo sincrono un metodo asincrono

Task.Run(() => asyncMethod()).Wait();

Non si verificheranno problemi di deadlock dovuti all'uso di Task.Run.

Fonte:

https://stackoverflow.com/a/32429753/3850405

Penso che anche il seguente metodo di supporto possa risolvere il problema.

private TResult InvokeAsyncFuncSynchronously<TResult>(Func< Task<TResult>> func)
    {
        TResult result = default(TResult);
        var autoResetEvent = new AutoResetEvent(false);

        Task.Run(async () =>
        {
            try
            {
                result = await func();
            }
            catch (Exception exc)
            {
                mErrorLogger.LogError(exc.ToString());
            }
            finally
            {
                autoResetEvent.Set();
            }
        });
        autoResetEvent.WaitOne();

        return result;
    }

Può essere utilizzato nel modo seguente:

InvokeAsyncFuncSynchronously(Service.GetCustomersAsync);

Questo funziona per me

using System;
using System.Collections.Generic;
using System.Linq;
using System.Net.Http;
using System.Text;
using System.Threading;
using System.Threading.Tasks;

namespace ConsoleApp2
{
    public static class AsyncHelper
    {
        private static readonly TaskFactory _myTaskFactory = new TaskFactory(CancellationToken.None, TaskCreationOptions.None, TaskContinuationOptions.None, TaskScheduler.Default);

        public static void RunSync(Func<Task> func)
        {
            _myTaskFactory.StartNew(func).Unwrap().GetAwaiter().GetResult();
        }

        public static TResult RunSync<TResult>(Func<Task<TResult>> func)
        {
            return _myTaskFactory.StartNew(func).Unwrap().GetAwaiter().GetResult();
        }
    }

    class SomeClass
    {
        public async Task<object> LoginAsync(object loginInfo)
        {
            return await Task.FromResult(0);
        }
        public object Login(object loginInfo)
        {
            return AsyncHelper.RunSync(() => LoginAsync(loginInfo));
            //return this.LoginAsync(loginInfo).Result.Content;
        }
    }
    class Program
    {
        static void Main(string[] args)
        {
            var someClass = new SomeClass();

            Console.WriteLine(someClass.Login(1));
            Console.ReadLine();
        }
    }
}

Ho scoperto che SpinWait funziona abbastanza bene per questo.

var task = Task.Run(()=>DoSomethingAsyncronous());

if(!SpinWait.SpinUntil(()=>task.IsComplete, TimeSpan.FromSeconds(30)))
{//Task didn't complete within 30 seconds, fail...
   return false;
}

return true;

L'approccio di cui sopra non ha bisogno di usare .Result o .Wait (). Ti consente anche di specificare un timeout in modo da non rimanere bloccato per sempre nel caso in cui l'attività non venga mai completata.

Su wp8:

Avvolgilo:

Task GetCustomersSynchronously()
{
    Task t = new Task(async () =>
    {
        myCustomers = await GetCustomers();
    }
    t.RunSynchronously();
}

Chiamalo:

GetCustomersSynchronously();

    private int GetSync()
    {
        try
        {
            ManualResetEvent mre = new ManualResetEvent(false);
            int result = null;

            Parallel.Invoke(async () =>
            {
                result = await SomeCalcAsync(5+5);
                mre.Set();
            });

            mre.WaitOne();
            return result;
        }
        catch (Exception)
        {
            return null;
        }
    }

Oppure potresti semplicemente andare con:

customerList = Task.Run<List<Customer>>(() => { return GetCustomers(); }).Result;

Per compilare questo accertarsi di fare riferimento al gruppo di estensioni:

System.Net.Http.Formatting

Prova il seguente codice funziona per me:

public async void TaskSearchOnTaskList (SearchModel searchModel)
{
    try
    {
        List<EventsTasksModel> taskSearchList = await Task.Run(
            () => MakeasyncSearchRequest(searchModel),
            cancelTaskSearchToken.Token);

        if (cancelTaskSearchToken.IsCancellationRequested
                || string.IsNullOrEmpty(rid_agendaview_search_eventsbox.Text))
        {
            return;
        }

        if (taskSearchList == null || taskSearchList[0].result == Constants.ZERO)
        {
            RunOnUiThread(() => {
                textViewNoMembers.Visibility = ViewStates.Visible;                  
                taskListView.Visibility = ViewStates.Gone;
            });

            taskSearchRecureList = null;

            return;
        }
        else
        {
            taskSearchRecureList = TaskFooterServiceLayer
                                       .GetRecurringEvent(taskSearchList);

            this.SetOnAdapter(taskSearchRecureList);
        }
    }
    catch (Exception ex)
    {
        Console.WriteLine("ActivityTaskFooter -> TaskSearchOnTaskList:" + ex.Message);
    }
}