Разработка своих асинхронных функций, какой шаблон верный?

Question

[Славка]

public Task<int> Foo()
    {
        var tcs = new TaskCompletionSource<int>();
        Task.Run(() => {
            var result = SomeAction();
            tcs.SetResult(result);
        });
        return tcs.Task;
    }

Никак не могу понять, какую пользу здесь играет класс TaskCompletionSource, почему писать return Task.Run(...) считается дурным тоном?

Answer 1

[Tom Nolane]

всегда пользуюсь так:
//для метода, который ничего не возвращает

public async Task Blabla()
{
    await Task.Run(()=>{

     //тут я что-то выполняю

     });
}

//для метода, который возвращает тип string (для примера)

public async Task<string> Blabla()
{
    return await Task.Run(()=>{

     return "я возвращаюсь!!!";

     });
}

и всё.

просто. работает. читабельно.

upd.
Петр - мэрси, напомнили)

upd2
Славка: вот тут ответ на то, где TaskCompletionSource применяется на практике

Comments

[Петр]

Очень плохая практика писать "async VOID" - theburningmonk.com/2012/10/c-beware-of-async-void-...

Answer 2

[Петр]

В вашем примере TaskCompletionSource точно лишний.
Достаточно:

public Task<int> Foo()
{
        return Task.Run(() => {
            return SomeAction();
        });
    }

Comments

[Славка]

Читая сейчас еще литературу, наткнулся на, то что TaskCompletionSource следуют применять для I/O операций, для вычислений просто Task.Run. Как я понимаю TaskCompletionSource дает выигрыш в производительности, позволяя быстрым асинхронным операциям выполняться синхронно, только как это происходит я понять не могу.

[Tom Nolane]

Славка: позволю себе дать ссылку на ответ: Петр :
Как работает TaskCompletionSource в C#?

только как это происходит я понять не могу.

вот тут вроде описывается как...

[Славка]

Tom Nolane: Читал, но так и не понял, Task.Run все равно запустит поток, просто код в потоке выполнится либо быстро, либо медленно и оповестит об этом другую задачу. Смею предположить что если перед запуском потока сделать проверку на кэш, тогда у tcs сразу можно выставить резалт и не создавать новый поток. Вот тогда я вижу смысл.

[Tom Nolane]

Славка: Task находится в библиотеке TPL (Task Parallel Library) - которая непосредственно управляет потоками (пулом). И TPL решает - давать поток на выполнение или нет (если есть свободный). Т.е. если используете Thread - то создаёте отдельный поток для себя (с накладными расходами). Если Task то Task берется из пула потоков (следовательно накладных расходов по созданию практически нет, и Task "прыгает" из потока в поток или вовсе не находится ни в каком потоке), но если "переборщить" - то скорее всего вы "проиграете" нежели "выиграете" от эффективности. Но, если Task не используется - он попросту "засыпает" (например ждёте response ответа от сервера). если бы использовали Thread - то "часть" ресурсов просто бы простаивала (использовалась в пустую).

Это я к чему? - в большинстве случаев используют Task. И многое зависит даже не от самого Task - а от TPL (сколько свободных потоков есть в пуле). А это зависит от кол-во ядер в процессоре и его возможностей в многопоточности, сколько уже потоков запущено/используется...

[Tom Nolane]

Славка: и как мы с Петр написали - это "синтаксический сахар" - позволяющий максимально эффективно использовать парализацию без углубления в детали - как это работает (без указания на низком уровне что делать) и лишнего кода