Когда следует использовать TaskCompletionSource <T>?

AFAIK, все, что он знает, - это то, что в какой-то момент вызывается его метод SetResultили SetExceptionметод для завершения Task<T>экспонирования через его Taskсвойство.

Другими словами, он выступает в качестве производителя для Task<TResult>и его завершения.

Я видел здесь пример:

Если мне нужен способ выполнить Func асинхронно и иметь задачу для представления этой операции.

public static Task<T> RunAsync<T>(Func<T> function) 
{ 
    if (function == null) throw new ArgumentNullException(“function”); 
    var tcs = new TaskCompletionSource<T>(); 
    ThreadPool.QueueUserWorkItem(_ => 
    { 
        try 
        {  
            T result = function(); 
            tcs.SetResult(result);  
        } 
        catch(Exception exc) { tcs.SetException(exc); } 
    }); 
    return tcs.Task; 
}

Который может быть использован *, если у меня не было Task.Factory.StartNew- но у меня есть Task.Factory.StartNew.

Вопрос:

Может кто - то пожалуйста , объясните на примере сценарий , связанный непосредственно с , TaskCompletionSource а не к гипотетической ситуации , в которой у меня нет Task.Factory.StartNew?

Я в основном использую его, когда доступен только API, основанный на событиях ( например, сокеты Windows Phone 8 ):

public Task<Args> SomeApiWrapper()
{
    TaskCompletionSource<Args> tcs = new TaskCompletionSource<Args>(); 

    var obj = new SomeApi();

    // will get raised, when the work is done
    obj.Done += (args) => 
    {
        // this will notify the caller 
        // of the SomeApiWrapper that 
        // the task just completed
        tcs.SetResult(args);
    }

    // start the work
    obj.Do();

    return tcs.Task;
}

Так что это особенно полезно, когда используется вместе с asyncключевым словом C # 5 .

По моему опыту, TaskCompletionSourceотлично подходит для упаковки старых асинхронных шаблонов в современныеasync/await шаблон.

Самый полезный пример, который я могу вспомнить, - это работа с Socket. У него есть старые шаблоны APM и EAP, но нет awaitable Taskметодов, которые TcpListenerи TcpClientесть.

У меня лично есть несколько проблем с NetworkStreamклассом, и я предпочитаю сырье Socket. Поскольку я также люблю async/awaitшаблон, я создал класс расширения, SocketExtenderкоторый создает несколько методов расширения Socket.

Все эти методы используют, TaskCompletionSource<T>чтобы обернуть асинхронные вызовы следующим образом:

    public static Task<Socket> AcceptAsync(this Socket socket)
    {
        if (socket == null)
            throw new ArgumentNullException("socket");

        var tcs = new TaskCompletionSource<Socket>();

        socket.BeginAccept(asyncResult =>
        {
            try
            {
                var s = asyncResult.AsyncState as Socket;
                var client = s.EndAccept(asyncResult);

                tcs.SetResult(client);
            }
            catch (Exception ex)
            {
                tcs.SetException(ex);
            }

        }, socket);

        return tcs.Task;
    }

Я передаю socketвBeginAccept методы, так что я получаю небольшое повышение производительности от компилятора, которому не нужно поднимать локальный параметр.

Тогда красота всего этого:

 var listener = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
 listener.Bind(new IPEndPoint(IPAddress.Loopback, 2610));
 listener.Listen(10);

 var client = await listener.AcceptAsync();

Для меня классический сценарий использования TaskCompletionSource- это когда возможно, что мой метод не обязательно должен выполнять длительную операцию. Это позволяет нам выбирать конкретные случаи, когда мы хотели бы использовать новый поток.

Хороший пример для этого, когда вы используете кеш. У вас может быть GetResourceAsyncметод, который ищет в кэше запрошенный ресурс и сразу же возвращает (не используя новый поток, используя TaskCompletionSource), если ресурс был найден. Только если ресурс не найден, мы хотели бы использовать новый поток и получить его с помощью Task.Run().

Пример кода можно посмотреть здесь: Как условно выполнить код асинхронно с помощью задач

В этом сообщении в блоге Леви Ботелхо описывает, как использовать TaskCompletionSourceдля написания асинхронной оболочки для Процесса, чтобы вы могли запустить его и дождаться его завершения.

public static Task RunProcessAsync(string processPath)
{
    var tcs = new TaskCompletionSource<object>();
    var process = new Process
    {
        EnableRaisingEvents = true,
        StartInfo = new ProcessStartInfo(processPath)
        {
            RedirectStandardError = true,
            UseShellExecute = false
        }
    };
    process.Exited += (sender, args) =>
    {
        if (process.ExitCode != 0)
        {
            var errorMessage = process.StandardError.ReadToEnd();
            tcs.SetException(new InvalidOperationException("The process did not exit correctly. " +
                "The corresponding error message was: " + errorMessage));
        }
        else
        {
            tcs.SetResult(null);
        }
        process.Dispose();
    };
    process.Start();
    return tcs.Task;
}

и его использование

await RunProcessAsync("myexecutable.exe");

Похоже, никто не упомянул, но я думаю, что юнит-тесты тоже можно считать реальной жизнью .

Я считаю TaskCompletionSourceполезным при насмешке зависимости с помощью асинхронного метода.

В реальной тестируемой программе:

public interface IEntityFacade
{
  Task<Entity> GetByIdAsync(string id);
}

В модульных тестах:

// set up mock dependency (here with NSubstitute)

TaskCompletionSource<Entity> queryTaskDriver = new TaskCompletionSource<Entity>();

IEntityFacade entityFacade = Substitute.For<IEntityFacade>();

entityFacade.GetByIdAsync(Arg.Any<string>()).Returns(queryTaskDriver.Task);

// later on, in the "Act" phase

private void When_Task_Completes_Successfully()
{
  queryTaskDriver.SetResult(someExpectedEntity);
  // ...
}

private void When_Task_Gives_Error()
{
  queryTaskDriver.SetException(someExpectedException);
  // ...
}

В конце концов, такое использование TaskCompletionSource кажется еще одним случаем «объекта Task, который не выполняет код».

TaskCompletionSource используется для создания объектов Task, которые не выполняют код. В реальных сценариях TaskCompletionSource идеально подходит для операций ввода-вывода. Таким образом, вы получаете все преимущества задач (например, возвращаемые значения, продолжения и т. Д.), Не блокируя поток на время выполнения операции. Если ваша «функция» связана с операциями ввода-вывода, не рекомендуется блокировать поток с помощью новой задачи . Вместо этого, используя TaskCompletionSource , вы можете создать подчиненную задачу, чтобы просто указать, когда ваша связанная операция ввода-вывода завершается или происходит сбой.

В этом посте приведен реальный пример с достойным объяснением из блога «Параллельное программирование с .NET» . Вы действительно должны прочитать это, но вот резюме в любом случае.

В сообщении блога показаны две реализации:

«фабричный метод для создания« отложенных »задач, которые на самом деле не будут запланированы, пока не произойдет какой-то заданный пользователем тайм-аут».

Первая показанная реализация основана на Task<>двух основных недостатках и имеет их. Во втором посте о внедрении они смягчаются с помощью TaskCompletionSource<>.

Вот эта вторая реализация:

public static Task StartNewDelayed(int millisecondsDelay, Action action)
{
    // Validate arguments
    if (millisecondsDelay < 0)
        throw new ArgumentOutOfRangeException("millisecondsDelay");
    if (action == null) throw new ArgumentNullException("action");

    // Create a trigger used to start the task
    var tcs = new TaskCompletionSource<object>();

    // Start a timer that will trigger it
    var timer = new Timer(
        _ => tcs.SetResult(null), null, millisecondsDelay, Timeout.Infinite);

    // Create and return a task that will be scheduled when the trigger fires.
    return tcs.Task.ContinueWith(_ =>
    {
        timer.Dispose();
        action();
    });
}

Это может быть упрощением, но источник TaskCompletion позволяет ожидать события. Поскольку tcs.SetResult устанавливается только при возникновении события, вызывающая сторона может ожидать выполнения задачи.

Посмотрите это видео, чтобы узнать больше:

http://channel9.msdn.com/Series/Three-Essential-Tips-for-Async/Lucian03-TipsForAsyncThreadsAndDatabinding

Я в реальном мире сценарий, где я использовал TaskCompletionSourceпри реализации очереди загрузки. В моем случае, если пользователь запускает 100 загрузок, я не хочу запускать их все сразу, и вместо того, чтобы возвращать объявленную задачу, я возвращаю задачу, к которой прикреплен TaskCompletionSource. После завершения загрузки поток, работающий в очереди, завершает задачу.

Ключевой концепцией здесь является то, что я отделяюсь, когда клиент запрашивает запуск задачи с момента ее фактического запуска. В этом случае, потому что я не хочу, чтобы клиенту приходилось иметь дело с управлением ресурсами.

обратите внимание, что вы можете использовать async / await в .net 4, если вы используете компилятор C # 5 (VS 2012+), смотрите здесь для получения дополнительной информации.

Я использовал TaskCompletionSourceдля запуска задачи, пока она не будет отменена. В этом случае это подписчик ServiceBus, который я обычно хочу запускать до тех пор, пока приложение работает.

public async Task RunUntilCancellation(
    CancellationToken cancellationToken,
    Func<Task> onCancel)
{
    var doneReceiving = new TaskCompletionSource<bool>();

    cancellationToken.Register(
        async () =>
        {
            await onCancel();
            doneReceiving.SetResult(true); // Signal to quit message listener
        });

    await doneReceiving.Task.ConfigureAwait(false); // Listen until quit signal is received.
}

TaskCompletionSourceЗадачи, как WaitHandleтемы. И поэтому мы можем использовать TaskCompletionSource для выполнения точной сигнализации .

Примером является мой ответ на этот вопрос: задержка ContentDialog после нажатия кнопки ОК