Спасибо. Если будет много комментариев такой же направленности, то исправлю на "встроенные функции". Мне кажется, если не характеристики, то "встроенные функции" является наиболее близким термином. Но в данном случае, все же, под intrinsics подразумеваются .NET-обертка над аппаратными командами. Оставлять термин без перевода мне кажется неверным. Надо стараться найти хороший, точный эквивалент на русском, только если его нет — оставлять транслитерацию.
Для того чтобы это понять, достаточно рассмотреть как работает контекст в WinForms, и добавить что очередь на обработку разбирается не одним потоком, а набором потоков из отдельного пула. И ConfigureAwait, в таком случае, сильно связан с вопросом, из какого пула будет взят поток для выполнения задачи.
Об этом, и не только, написано в статье "Parallel Computing — It's All About the SynchronizationContext". Достаточно просто внимательно ее прочесть.
Простой пример, когда библиотечный ConfigureAwait(false) все ломает: Если в приложении есть некоторые набор критических задач, который должны гарантированно работать, т.е. их приоритет высок, то таким задачам можно дать свой набор потоков, свою пул потоков. В этом случае контекст синхронизации важен, он не даст уйти из этого пула: все асинхронные вызовы будут возвращаться в этот "критический" пул, и продолжать работать на выделенных, для этого набора критических задач, потоках. Если же у вас библиотека внутри написана с ConfigureAwait(false), то вызовы ее методов, в конечном итоге, выходят из выделенного пула, на стандартный. Это значит, что если стандартный пул "просядет", то "просядут" и наши критические задача, а такого быть не должно.
Вырожденный случай — когда у нас есть одна критически важная операция, ей выделяют отдельный поток, который, условлено, никто не блокирует. Все действия этой операции должны выполняться в этом потоке, чтобы никакая нагрузка на стандартный пул эту задачу не задела.
В описанных ситуациях, четко видно, что разработчик клиентского кода, должен определять когда нужно использовать контекст, а когда не нужно. Клиентский код, а не код библиотеки.
Выбор должен быть за клиентским кодом. Клиентский код не имеет доступа к исходникам библиотеки. Если клиентский код, в свою очередь, это тоже код библиотеки, то как ему указать что на всех уровнях надо (или же не надо) работать с контекстом?
Пример (7) показывает зачем нужен параметр, если бы разработчик метода FooAsync предусмотрел параметр, то клиент не встал бы на взаимоблокировке. А без параметра, можно лишь надеяться что внутри все верно, либо же писать дополнительный код, для обхода проблемы.
По моему мнению, статья — перевод статьи десятилетней давности, это просто дурной тон, или вкус, или и то и другое. Тем более, когда есть более свежие статьи, на самом же хабре, в которых раскрыто больше информации чем в исходной. К примеру эта.
Если исходить из примеров, а так же из логики что «тот лучше, для правильного использования которого надо читать меньше документации», то Unity лучший из представленных: почти во всех примерах используется один способ регистрации. Далее, способ регистрации и внедрения важны, но есть и еще один, не менее важный, вопрос — управление жизненным циклом объектов, особенно в части IDisposable.
Возможно. Хотя для меня этот термин больше связан с математикой например в этом смысле или в этом.
Спасибо. Если будет много комментариев такой же направленности, то исправлю на "встроенные функции". Мне кажется, если не характеристики, то "встроенные функции" является наиболее близким термином. Но в данном случае, все же, под intrinsics подразумеваются .NET-обертка над аппаратными командами. Оставлять термин без перевода мне кажется неверным. Надо стараться найти хороший, точный эквивалент на русском, только если его нет — оставлять транслитерацию.
Да, мой русский страдает. Спасибо. В будущем буду пользоваться каким-нибудь "ОРФО".
К сожалению, я не видел этого перевода, иначе не стал бы переводить и публиковать.
"deep reinforcement learning hands-on" еще можно?
Для того чтобы это понять, достаточно рассмотреть как работает контекст в WinForms, и добавить что очередь на обработку разбирается не одним потоком, а набором потоков из отдельного пула. И ConfigureAwait, в таком случае, сильно связан с вопросом, из какого пула будет взят поток для выполнения задачи.
Об этом, и не только, написано в статье "Parallel Computing — It's All About the SynchronizationContext". Достаточно просто внимательно ее прочесть.
Удалил комментарий, дублирует предыдущий.
Простой пример, когда библиотечный ConfigureAwait(false) все ломает: Если в приложении есть некоторые набор критических задач, который должны гарантированно работать, т.е. их приоритет высок, то таким задачам можно дать свой набор потоков, свою пул потоков. В этом случае контекст синхронизации важен, он не даст уйти из этого пула: все асинхронные вызовы будут возвращаться в этот "критический" пул, и продолжать работать на выделенных, для этого набора критических задач, потоках. Если же у вас библиотека внутри написана с ConfigureAwait(false), то вызовы ее методов, в конечном итоге, выходят из выделенного пула, на стандартный. Это значит, что если стандартный пул "просядет", то "просядут" и наши критические задача, а такого быть не должно.
Вырожденный случай — когда у нас есть одна критически важная операция, ей выделяют отдельный поток, который, условлено, никто не блокирует. Все действия этой операции должны выполняться в этом потоке, чтобы никакая нагрузка на стандартный пул эту задачу не задела.
В описанных ситуациях, четко видно, что разработчик клиентского кода, должен определять когда нужно использовать контекст, а когда не нужно. Клиентский код, а не код библиотеки.
Выбор должен быть за клиентским кодом. Клиентский код не имеет доступа к исходникам библиотеки. Если клиентский код, в свою очередь, это тоже код библиотеки, то как ему указать что на всех уровнях надо (или же не надо) работать с контекстом?
Пример (7) показывает зачем нужен параметр, если бы разработчик метода FooAsync предусмотрел параметр, то клиент не встал бы на взаимоблокировке. А без параметра, можно лишь надеяться что внутри все верно, либо же писать дополнительный код, для обхода проблемы.
По моему мнению, статья — перевод статьи десятилетней давности, это просто дурной тон, или вкус, или и то и другое. Тем более, когда есть более свежие статьи, на самом же хабре, в которых раскрыто больше информации чем в исходной. К примеру эта.