2015-03-01 3 views
1

При использовании потока логично ли использовать делегат async? Например, предположим, что у нас есть служба WCF SOAP, и у нас есть клиентское настольное приложение, которое потребляет службы WCF. В этом приложении мы должны иметь как синхронные, так и асинхронные механизмы, поэтому иногда нам нужно использовать потоки, а иногда и асинхронные задачи. Теперь при условии, что мы должны потреблять службы WCF в потоке, так что мы можем написать нить в двух формах:делегат Async для потока

Thread Worker = new Thread (()=>{ 
    WCFServerClient client = new WCFServiceClient(); 
    var GetData = client.GetData(new GetDataRequest()); 
}); 

Thread Worker = new Thread (async()=>{ 
    WCFServerClient client = new WCFServiceClient(); 
    var GetData = await client.GetDataAsync(new GetDataRequest()); 
}); 

Какой из них более логично? Я имею в виду, имеет ли смысл вообще идти на второй вариант. Запрашивать это, потому что первое также не влияет на отзывчивость в приложении.

+0

Лучшее решение - использовать 'Task' вместо' Thread': 'Task worker = Task.Run (async() => ...);' –

+0

@StephenCleary: Почему Стефан, с точки зрения задачи лучше. Если вы не возражаете, объясните. (Я получил жадность для информации) – James

+1

Легче получить результаты и исключения. Полное описание [в моем блоге] (http://blog.stephencleary.com/2010/08/various-implementations-of-asynchronous.html). –

ответ

3

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

Так в чем же разница в поведении?

Во втором примере поток, который вы создали, завершится до того, как завершится GetData. Когда GetData завершено, ваш код будет продолжен в другом потоке, взятом из пула потоков.

Оба являются «логическими», но лучше или не зависит от ваших требований к использованию.

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

Однако, если ваше приложение уже использует максимальное количество потоков пулов потоков, может возникнуть ожидание обработки возвращенных данных, поскольку вы ожидаете, что поток пула потоков станет доступным.

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

+0

Итак, второй вариант - более дружелюбный к ЦП, если я не ошибаюсь, верно? – James

+1

@ Джеймс - Подозреваю, что нет. Второй вариант - более дружелюбный к ресурсам, но не более удобный для ЦП.Это займет процессорные циклы, чтобы объединить все, а затем отправить все это в объединенный поток позже. Но мы говорим о крошечных количествах. –

Смежные вопросы