Ведь все асинхронные методы можно вызывать синхронно и от старых API не убудет. Т. е. можно подсовывать асинки вместо обычных методов старым программам и всё будет хорошо, а новые могут и поавейтить, чтобы воспользоваться преимуществом?

Единственное, я не понял, если запустить код с ключевым словом async на старом фреймворке - 3, 3.5 там, он не выдаст ли ошибку, что такого ключевого слова нет, и не не захочет ли компилироваться?

Просто смотрю, щас некоторые API (например, генератор прокси-классов для WCF) по-умолчанию создают пару async-не async методов. Скоро, видать, вообще только асинки генерить будут.

Dima TDude42Скоро, видать, вообще только асинки генерить будут.
Не будут. Асинхронность не бесплатна. Использование одного и того же объекта из разных потоков требует синхронизации доступа к данным внутри объекта, т.е. потокобезопасность. У большинства классов она гарантирована только статическим методам, исключение классы Concurrent*
Тормоза из-за синхронизации получаются значительные. Затести например скорость работы Dictionary<> и ConcurrentDictionary<>
Вы не поняли. Я имел ввиду, что просто все методы делать async, вне зависимости от их потокобезопасности, а будет ли пользователь их применять сихнронно или асинхронно - его дело. В комментариях а API, конечно, упоминать, что этот де метод потокобезопасен, а этот - нет. Само слово async, вроде, ниде в C# не гарантирует потокобезопасность, а всего лишь означает, что этот метод можно "ожидать" (await). Т. е. наличие слова async это не соглашение о потокобезопасности метода ("async isn't a part of the signature, so you don't actually need to be concerned with whether the method implementing the interface is async or not").

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

Просто смотрю, в новых статьях многие модные челы вообще всё асинками делают - обработчики событий в настольных приложениях, методы контроллеров в ASP.NET MVC приложениях и т. п. Хотя, например, по второму варианту один гуру асинков не рекомендует так уж бездумно пихать их везде ("That’s why one of the principles of ASP.NET is to avoid using thread pool threads (except for the request thread that ASP.NET gives you, of course).").



Или всё же писать методы с таким ключевым словом нужно только для явно потокобезопасных методов? Ну и, раз async не часть сигнатуры, то придётся таки как-то обозначить потокобезопасность в сигнатуре - например, добавив слово async в имя метода (типа MyMethodAsync)?

ЕвгенийВDude42 Т. е. можно подсовывать асинки вместо обычных методов старым программам и всё будет хорошо, а новые могут и поавейтить, чтобы воспользоваться преимуществом?

Всегда надо думать и понимать что делаешь, а иначе не видать удачи.
Вот Алексей правильно сказал, что не надо путать асинхронность и многопоточность. Добавляя async, я всего лишь даю возможность выполнить метод асинхронно. Async это не соглашение о потокобезопасности. Если вы вызываете асинхронный метод много раз "подряд", создавая конкуренцию между потоками, то это ваши проблемы. А я всего лишь позволил выполнить этот метод в другом потоке "хотя бы один раз", не гарантирую потокобезопасности. Про потокобезопасность я либо пишу в комментариях к методу, либо создаю соглашение - например, добавляя в потокобезопасном методе какое-нибудь ключевое слово к имени метода, либо вообще вынося такие методы в отдельное пространство имён, как в Concurrent Collections в .NET сделали.

Правильно я рассуждаю? Т. е. таки можно писать вообще все методы с ключевым словом async? Я бы даже сказал - нужно?

авторДобавляя async, я всего лишь даю возможность выполнить метод асинхронно.
Всё ещё проще. Я всего лишь позволяю выполнить метод асинхронно с помощью удобного синтаксического сахара с помощью слова await. Ведь вам и раньше никто не мешал выполнять любые методы асинхронно - в Task.Run(() => ...) можно запихнуть вообще любой метод.

авторВсё ещё проще. Я всего лишь позволяю выполнить метод асинхронно с помощью удобного синтаксического сахара с помощью слова await. Ведь вам и раньше никто не мешал выполнять любые методы асинхронно - в Task.Run(() => ...) можно запихнуть вообще любой метод.
Т. е. асинхронно можно было выполнить метод всегда (по крайней мере, с момента появления Task, если не считать класс Thread). Просто сейчас добавление слова async вообще к любому методу - это такое правило хорошего тона, или, лучше сказать, "современный код", соответствующий последним версиям фреймворка, где можно "эвейтить" вообще любой код.

Где-то на Хабре встречал коммент, что в UWP вообще все методы - async. И это кому-то мешало своей непривычностью, чтоли.

Резюмируя - склоняюсь к этому:

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

авторПро потокобезопасность я либо пишу в комментариях к методу, либо создаю соглашение - например, добавляя в потокобезопасном методе какое-нибудь ключевое слово к имени метода (например, добавив слово async в имя метода - типа MyMethodAsync), либо вообще вынося такие методы в отдельное пространство имён, как в Concurrent Collections в .NET сделали.

Что думаете?

А чего тогда в генераторе прокси для WCF по умолчанию галки расставлены на генерацию async-версий методов для сервиса? Вот я и подумал, что челы из команды .NET уже вовсю и везде асинки лепят по-умолчанию.

Или для сервисов таки имеет смысл все публичные методы делать с async? - Т. е. клиенту так и так приходится ожидать результата выполнения метода, так почему бы не сделать эти методы асинхроннымы по-умолчанию, да? Клиент уже сам решит, ожидать этот метод параллельно или последовательно, да?

Т. е. WCF - это одна из областей, где есть смысл вообще все публичные методы сделать по-умолчанию async, да?