method - task c# ejemplo

Use Task.Run() en el método síncrono para evitar el interbloqueo en espera en el método async?

Question

ACTUALIZAR El propósito de esta pregunta es obtener una respuesta simple sobre Task.Run() y deadlocking. Entiendo mucho el razonamiento teórico para no mezclar asincronía y sincronización, y los tomo en serio. No estoy por encima de aprender cosas nuevas de otros; Trato de hacer eso siempre que puedo. Hay momentos en que todo lo que un chico necesita es una respuesta técnica ...

Tengo un método Dispose() que necesita llamar a un método asíncrono. Como el 95% de mi código es asíncrono, la refactorización no es la mejor opción. Tener un IAsyncDisposable (entre otras características) que sea compatible con el framework sería ideal, pero aún no lo hemos logrado. Entonces, mientras tanto, necesito encontrar una forma confiable de llamar a los métodos asíncronos desde un método sincrónico sin interbloqueo.

Preferiría no usar ConfigureAwait(false) porque eso deja la responsabilidad dispersa en todo mi código para que el destinatario se comporte de cierta manera, en caso de que la persona que llama sea sincrónica. Prefiero hacer algo en el método sincrónico ya que es el insector desviado.

Después de leer el comentario de Stephen Cleary en otra pregunta que Task.Run() siempre programa en el grupo de subprocesos incluso en métodos asíncronos, me hizo pensar.

En .NET 4.5 en ASP.NET o cualquier otro contexto de sincronización que programe tareas para el hilo actual / el mismo hilo, si tengo un método asincrónico:

private async Task MyAsyncMethod()
{
    ...
}

Y quiero llamarlo desde un método sincrónico, ¿puedo usar Task.Run() con Wait() para evitar interbloqueos, ya que pone en cola el método async del grupo de subprocesos?

private void MySynchronousMethodLikeDisposeForExample()
{
    // MyAsyncMethod will get queued to the thread pool 
    // so it shouldn''t deadlock with the Wait() ??
    Task.Run((Func<Task>)MyAsyncMethod).Wait();
}

Answer 1

Con un pequeño contexto de sincronización personalizada, la función de sincronización puede esperar la finalización de la función asíncrona, sin crear un interbloqueo. El hilo original se conserva, por lo que el método de sincronización utiliza el mismo hilo antes y después de llamar a la función asíncrona. Aquí hay un pequeño ejemplo para la aplicación WinForms.

Imports System.Threading
Imports System.Runtime.CompilerServices

Public Class Form1

    Private Sub Form1_Load(sender As Object, e As EventArgs) Handles MyBase.Load
        SyncMethod()
    End Sub

    '' waiting inside Sync method for finishing async method
    Public Sub SyncMethod()
        Dim sc As New SC
        sc.WaitForTask(AsyncMethod())
        sc.Release()
    End Sub

    Public Async Function AsyncMethod() As Task(Of Boolean)
        Await Task.Delay(1000)
        Return True
    End Function

End Class

Public Class SC
    Inherits SynchronizationContext

    Dim OldContext As SynchronizationContext
    Dim ContextThread As Thread

    Sub New()
        OldContext = SynchronizationContext.Current
        ContextThread = Thread.CurrentThread
        SynchronizationContext.SetSynchronizationContext(Me)
    End Sub

    Dim DataAcquired As New Object
    Dim WorkWaitingCount As Long = 0
    Dim ExtProc As SendOrPostCallback
    Dim ExtProcArg As Object

    <MethodImpl(MethodImplOptions.Synchronized)>
    Public Overrides Sub Post(d As SendOrPostCallback, state As Object)
        Interlocked.Increment(WorkWaitingCount)
        Monitor.Enter(DataAcquired)
        ExtProc = d
        ExtProcArg = state
        AwakeThread()
        Monitor.Wait(DataAcquired)
        Monitor.Exit(DataAcquired)
    End Sub

    Dim ThreadSleep As Long = 0

    Private Sub AwakeThread()
        If Interlocked.Read(ThreadSleep) > 0 Then ContextThread.Resume()
    End Sub

    Public Sub WaitForTask(Tsk As Task)
        Dim aw = Tsk.GetAwaiter

        If aw.IsCompleted Then Exit Sub

        While Interlocked.Read(WorkWaitingCount) > 0 Or aw.IsCompleted = False
            If Interlocked.Read(WorkWaitingCount) = 0 Then
                Interlocked.Increment(ThreadSleep)
                ContextThread.Suspend()
                Interlocked.Decrement(ThreadSleep)
            Else
                Interlocked.Decrement(WorkWaitingCount)
                Monitor.Enter(DataAcquired)
                Dim Proc = ExtProc
                Dim ProcArg = ExtProcArg
                Monitor.Pulse(DataAcquired)
                Monitor.Exit(DataAcquired)
                Proc(ProcArg)
            End If
        End While

    End Sub

     Public Sub Release()
         SynchronizationContext.SetSynchronizationContext(OldContext)
     End Sub

End Class

Answer 2

Esta es mi forma de evitar el interbloqueo cuando tengo que llamar al método asincrónico sincrónicamente y el subproceso puede ser subproceso UI:

    public static T GetResultSafe<T>(this Task<T> task)
    {
        if (SynchronizationContext.Current == null)
            return task.Result;

        if (task.IsCompleted)
            return task.Result;

        var tcs = new TaskCompletionSource<T>();
        task.ContinueWith(t =>
        {
            var ex = t.Exception;
            if (ex != null)
                tcs.SetException(ex);
            else
                tcs.SetResult(t.Result);
        }, TaskScheduler.Default);

        return tcs.Task.Result;
    }

Answer 3

Este código no se estancará exactamente por los motivos que destacó en la pregunta: el código siempre se ejecuta sin contexto de sincronización (ya que usa el grupo de subprocesos) y Wait simplemente bloqueará el método de subprocesamiento hasta que el método retorne.

Answer 4

Parece que entiendes los riesgos que conlleva tu pregunta, así que me saltearé la conferencia.

Para responder a su pregunta real: Sí, puede usar Task.Run para descargar ese trabajo a un hilo de ThreadPool que no tiene un SynchronizationContext por lo que no existe un riesgo real de un punto muerto.

Sin embargo , usar otro subproceso simplemente porque no tiene SC es algo así como un truco y podría ser costoso, ya que la programación del trabajo que se debe realizar en el ThreadPool tiene sus costos.

Una solución mejor y más clara IMO sería simplemente eliminar el SC por el momento usando SynchronizationContext.SetSynchronizationContext y restaurarlo después. Esto se puede encapsular fácilmente en un IDisposable para que pueda usarlo en un ámbito de using :

public static class NoSynchronizationContextScope
{
    public static Disposable Enter()
    {
        var context = SynchronizationContext.Current;
        SynchronizationContext.SetSynchronizationContext(null);
        return new Disposable(context);
    }

    public struct Disposable : IDisposable
    {
        private readonly SynchronizationContext _synchronizationContext;

        public Disposable(SynchronizationContext synchronizationContext)
        {
            _synchronizationContext = synchronizationContext;
        }

        public void Dispose() =>
            SynchronizationContext.SetSynchronizationContext(_synchronizationContext);
    }
}

Uso:

private void MySynchronousMethodLikeDisposeForExample()
{
    using (NoSynchronizationContextScope.Enter())
    {
        MyAsyncMethod().Wait();
    }
}

Answer 5

Si absolutamente debe llamar al método asíncrono desde uno sincrónico, asegúrese de usar ConfigureAwait(false) dentro de sus llamadas al método asíncrono para evitar la captura del contexto de sincronización.

Esto debería mantenerse, pero es inestable en el mejor de los casos. Aconsejaría pensar en refactorizar. en lugar.