Posted on 21. March 2020

Обновление конструктора .NET Core Windows Forms

Microsoft выпустили предварительную версию Visual Studio 16.6 - Visual Studio 2019 версии 16.6 Preview 1 и вместе с ней новую версию .NET Core конструктора Windows Forms.

 

В этом релизе представлено

Поддержка следующих элементов управления:

·      FlowLayoutPanel,

·      GroupBox,

·      ImageList,

·      MenuStrip (через PropertyBrowser и контекстное меню),

·      Panel,

·      SplitContainer,

·      Splitter,

·      TabControl,

·      TableLayoutPanel,

·      ToolStrip (через  PropertyBrowser, контекстное меню  и дизайнерские действия).

○ Локальные ресурсы и локализованные формы были включены в конструкторе.

○ Поддержка для LayoutMode и ShowGrid/SnapToGrid настроек через Tools->Options.

○ Улучшение производительности и точности.

○ Другие мелкие исправления и правки.

 

Последование

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

 

Как пользоваться конструктором

• Вам нужно воспользоваться Visual Studio Preview channel

•Нужно включить конструктор в Visual Studio. Перейдите по  Tools > Options > Environment > Preview Features и выбрать опцию Use the preview Windows Forms designer for .NET Core apps.

 

Как сообщить о проблемах

Ваше мнение очень важно для Microsoft! Пожалуйста, сообщайте о проблемах и отправляйте запросы функций через канал обратной связи Visual Studio. Используйте значок «Отправить отзыв» в правом верхнем углу Visual Studio, как показано ниже, и укажите, что он связан с областью «WinForms .NET Core».

Источник



Exception: Object reference not set to an instance of an object.
Posted on 19. March 2020

Асинхронное объединение ValueTask в .NET 5

Функция async / await в C # произвела революцию в том, как разработчики, нацеленные на .NET, пишут асинхронный код. Прибавьте немного async и await, измените, некоторые типы возвращаемых данных на задачи, и вы получите асинхронную реализацию. Теоретически.

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

Распределения и конечные автоматы

Когда вы пишете асинхронный метод в C #, компилятор переписывает это в конечный автомат, где большая часть вашего кода в вашем асинхронном методе перемещается в MoveNext сгенерированного компилятором типа (структура в сборках Release),  и с этим MoveNext  завален переходами и метками, которые позволяют методу приостановить и резюмировать в пункты  await. К незавершенным задачам await подключено продолжение (обратный вызов), которое при окончательном завершении задачи вызывает метод MoveNext и переходит к месту, где функция была приостановлена. Для того чтобы локальные переменные могли поддерживать свое состояние через эти выходы и повторные входы метода, соответствующие «локальные объекты» переписываются компилятором в поля типа конечного автомата. И для того, чтобы этот конечный автомат как структура сохранялся в тех же самых приостановках, он должен быть перемещен в кучу.

Компилятор C # и среда выполнения .NET изо всех сил стараются не помещать этот конечный автомат в кучу. Многие вызовы асинхронных методов фактически завершаются синхронно, и компилятор и среда выполнения настраиваются на этот вариант использования.  Как указано, в релизном билде, конечный автомат, сгенерированный компилятором, является структурой, и когда вызывается асинхронный метод, конечный автомат начинает свою жизнь в стеке. Если асинхронный метод завершается без приостановки, конечный автомат успешно завершится, никогда не вызывая распределение. Однако, если асинхронный метод когда-либо нужно приостановить, конечный автомат должен быть каким-то образом собран.

В .NET Framework, момент Task или  ValueTask возвращение асинхронного метода (как общего, так и не универсального) приостанавливается впервые, происходит несколько выделений:

1. Структура конечного автомата копируется в кучу через стандартный бокс времени выполнения; каждый конечный автомат реализует IAsyncStateMachine  интерфейс, среда выполнения буквально приводит структуру к этому интерфейсу.

2. Среда выполнения фиксирует текущий ExecutionContext а затем выделяет объект (он называет это «бегун»), который он использует для хранения обоих конечных автоматов в штучной упаковке и ExecutionContext  (обратите внимание, что в .NET Framework, регистрация ExecutionContext  если это не значение по умолчанию, это также приводит к одному или нескольким выделениям).

3. Среда выполнения выделяет Action , который указывает на метод в этом объекте запуска, потому что шаблон ожидающего требует Action  которые будут переданы ожидающему методу {Unsafe}OnCompleted; при вызове Action будет использовать ExecutionContext для вызова метода MoveNext на конечном компьютере.

4. Среда выполнения выделяет объект Task, который будет завершен после завершения асинхронного метода и это возвращается из асинхронного метода к его синхронному вызывающему (если асинхронный метод набран для возврата ValueTask, структура ValueTask просто оборачивается вокруг объекта Task).

Это как минимум четыре средства, когда асинхронный метод в первый раз приостанавливается. Кроме того, каждый последующий раз асинхронный метод приостанавливается, если мы окажемся с нестандартным ExecutionContext  (например, он переносит состояние для AsyncLocal<T>),  среда выполнения перераспределяет это в запускающийся объект, затем перераспределяет действие, которое указывает на него (потому что делегаты неизменны), каждый раз выполняя минимум два дополнительных выделения, когда асинхронный метод приостанавливается после первого раза. Вот простое повторение этого в Visual Studio с правым окном, в котором отображаются распределения в соответствии с инструментом отслеживания распределения объектов .NET:

Это было значительно улучшено, в .NET Core, особенно с .NET Core 2.1. Когда асинхронный метод приостанавливается, выделяется Task. Но это не базовый тип Task или Task<TResult>. Структура конечного автомата хранится в строго типизированном поле для этого производного типа, устранение необходимости в отдельном распределении бокса. Этот тип также имеет поле для захваченного ExecutionContext (который является неизменным в .NET Core, это означает что захват никогда не выделяется), нам не нужен отдельный объект ранера. И у среды выполнения теперь есть специальные пути кода, которые поддерживают передачу этого типа AsyncStateMachineBox<TStateMachine> напрямую всем ожидающим, о которых среда выполнения знает, это означает, что пока асинхронный метод ожидает только TaskTask<TResult>ValueTask или ValueTask<TResult> (напрямую или через их аналоги ConfigureAwait), ему вообще не нужно выделять Action. Затем, поскольку у нас есть прямой доступ к полю ExecutionContext, последующие приостановки не требуют выделения нового участника (участники полностью отсутствуют), это также означает, что даже если нам нужно было распределить действие, нам не нужно его перераспределять. Это значит, тогда как в .NET Framework у нас есть как минимум четыре выделения для первой приостановки и часто по крайней мере два распределения для каждой последующей приостановки, в .NET Core у нас есть одно распределение для первого приостановления (наихудший случай два, если используются пользовательские ожидающие), и это все. Другие изменения, такие как переписывание инфраструктуры очередей ThreadPool, также значительно сократили распределение.

 

Это изменение оказало очень ощутимое влияние на производительность (и, как оказалось, не только на производительность; оно также очень полезно для отладки), и мы все можем радоваться удалению ненужных ассигнований. Однако, как уже было отмечено, одно распределение все еще остается, когда асинхронный метод завершается асинхронно. Но ... что если мы тоже сможем избавиться от этого?  Что если бы мы могли сделать так, чтобы вызов асинхронного метода имел (амортизировался) накладные расходы при нулевом распределении независимо от того, завершился он синхронно или асинхронно?

ValueTask

ValueTask<TResult> был введен в период .NET Core 1.0, чтобы помочь разработчикам избежать выделения ресурсов,  когда асинхронные методы завершаются синхронно. Это была относительно простая структура, представляющая различаемое объединение между TResult и Task<TResult>. При использовании в качестве типа результата асинхронного метода, если вызов асинхронного метода возвращается синхронно, независимо от значения результата TResult, метод требует нулевого распределения накладных расходов: конечный автомат не нужно перемещать в кучу, и нет необходимости в задании Task<TResult> для результата; значение результата просто сохраняется в поле TResult возвращенной ValueTask<TResult>. Однако, если асинхронный метод завершается асинхронно, среда выполнения возвращается к поведению так же, как и в случае с задачей Task<TResult>: он создает единственную задачу AsyncStateMachineBox<TStateMachine>, который затем возвращается в структуру ValueTask<TResult>.

В .NET Core 2.1 мы представили интерфейс IValueTaskSource<TResult>, наряду с неуниверсальными аналогами ValueTask и IValueTaskSource. Мы также сделали ValueTask<TResult> способным хранить не только TResult, но и Task<TResult>, но также IValueTaskSource<TResult> (то же самое для неуниверсального ValueTask, который, может хранить Task или IValueTaskSource). Этот продвинутый интерфейс позволяет предприимчивому разработчику написать свое собственное резервное хранилище для задачи,  и они могут делать это таким образом, чтобы повторно использовать этот объект хранилища резервных копий для нескольких не параллельных операций (намного больше информации об этом доступно в этом посте). Например, Socket обычно используется не более чем для одной операции приема и одна операция отправки за раз. Socket  был изменен для хранения повторно используемого / сбрасываемого IValueTaskSource<int> для каждого направления и каждой последующей операции чтения или записи что завершает и асинхронно раздает ValueTask<int>, поддерживаемый соответствующим общим экземпляром. Это означает, что в подавляющем большинстве случаев методы ReceiveAsync/SendAsync на основе ValueTask<int> в Socket  в конечном итоге не выделяются, независимо от того, выполняются они синхронно или асинхронно.  Несколько типов получили эту обработку, но только в тех случаях, где это будет действенно.

Таким образом, в .NET Core 2.1 были добавлены несколько реализаций в ключевых областях, таких как System.Net.SocketsSystem.Threading.Channels и System.IO.Pipelines, но не намного дальше. Впоследствии мы ввели тип ManualResetValueTaskSource<TResult>, чтобы упростить такие реализации, и в результате было добавлено больше реализаций этих интерфейсов в .NET Core 3.0, а также в .NET 5, хотя в основном внутри различных компонентов, таких как System.Net.Http.

Улучшения в .NET 5

В .NET 5 мы дальше экспериментируем с этой оптимизацией. С .NET 5 Preview 1, если до запуска вашего процесса для переменной среды DOTNET_SYSTEM_THREADING_POOLASYNCVALUETASKS установлено значение true  или 1, среда выполнения будет использовать объекты конечного автомата, которые реализуют интерфейсы IValueTaskSource и IValueTaskSource<TResult>. Он будет объединять объекты, которые создает, для возвращенных экземпляров из асинхронных методов async ValueTask  или async ValueTask<TResult>. Итак, если, как и в предыдущем примере, вы повторно вызываете один и тот же метод и ожидаете результата, каждый раз, когда вы в конечном итоге получите ValueTask, который оборачивает один и тот же объект, просто сбрасывайте его каждый раз, чтобы позволить отслеживать другое выполнение. Магия.


Почему он не включен по умолчанию прямо сейчас? Две основные причины:

1. Объединение не является бесплатным. Разработчик может оптимизировать свой код различными способами. Один из них - просто улучшить код, чтобы больше не нуждаться в выделении; с точки зрения производительности это, как правило, очень низкий риск. Другой - повторно использовать уже доступный объект, например, добавив дополнительное поле к существующему объекту с аналогичным сроком службы; это все еще требует более подробного анализа производительности. Затем приходит объединение. Оно может быть очень полезным, когда создание объединяемой вещи очень ценно; хорошим примером этого является пул соединений HTTPS, где стоимость установления нового безопасного соединения, как правило, на несколько порядков дороже, чем доступ к нему даже в самой наивной структуре пулов данных. Более спорная форма объединения - это когда пул предназначен для дешевых объектов с целью избежать затрат на сборку мусора. Используя такой пул, разработчик делает ставку на то, что он может реализовать собственный распределитель (который действительно является пулом), который лучше, чем универсальный распределитель GC. Победить в сборной нетривиально. Но разработчик может это сделать, учитывая знания, которые они имеют в своем конкретном сценарии. Например, .NET GC очень хорошо умеет эффективно собирать недолговечные объекты, которые становятся коллекционными в поколении 0, и попытка объединения таких объектов может легко сделать программу более дорогой (даже если это выглядит хорошо на микробенчмарке, сфокусированном на измерении распределения). Но если вы знаете, что ваши объекты, вероятно, выживут в gen0, например, если они используются для представления потенциально асинхронных операций с большой задержкой, вполне возможно, что пользовательский пул может сбрить некоторые накладные расходы. Мы еще не сделали этот асинхронный пул async ValueTask по умолчанию, потому что, хотя он хорошо выглядит на микробенчмарках, мы не уверены, что это действительно значительное улучшение рабочих нагрузок в реальном мире.

2. ValueTasks имеют ограничения. Типы Task  и Task<TResult> были разработаны, чтобы быть очень надежными. Вы можете их кешировать. Вы можете ждать их любое количество. Они поддерживают несколько продолжений. Они потокобезопасны, с любым количеством потоков, способных одновременно регистрировать продолжения. И в дополнение к ожиданию и поддержке асинхронных уведомлений о завершении, они также поддерживают модель блокировки, при этом синхронные абоненты могут ожидать получения результата. Ничто из этого не относится к ValueTask и ValueTask<TResult>. Потому что они могут быть поддержаны сбрасываемыми экземплярами IValueTaskSource, вы не должны их кэшировать (то, что они переносят, может быть использовано повторно) и не ждать их несколько раз. Вы не должны пытаться зарегистрировать несколько продолжений (после первого завершения объект может попытаться сбросить себя для другой операции), будь то одновременно или нет. И вы не должны пытаться блокировать ожидание их завершения (реализации IValueTaskSource не должны предоставлять такую семантику). Пока вызывающие абоненты напрямую ожидают результата вызова метода, который возвращает  ValueTask или ValueTask<TResult>, все должно работать хорошо, но как только кто-то сходит с этого золотого пути, все может быстро измениться; это может означать получение исключений или коррупцию в процессе. Кроме того, эти сложности обычно проявляются только тогда, когда ValueTask или ValueTask<TResult> переносят реализацию IValueTaskSource; когда они переносят Task, вещи обычно «просто работают», так как ValueTask наследует надежность Task, и когда они оборачивают необработанное значение результата, ограничения технически вообще не применяются. И это означает, что, переключая асинхронные методы async ValueTask с поддержкой Task, вместо поддержки этих объединенных реализаций IValueTaskSource, мы могли бы выявлять скрытые ошибки в приложении разработчика, либо напрямую, либо через библиотеки, которые они используют. Предстоящий выпуск Roslyn Analyzers будет включать в себя анализатор, который должен помочь найти большинство нецелевых использований.

Призыв к действию

Если у вас есть приложение, которому, по вашему мнению, будет полезно это объединение, мы будем рады получить от вас сообщение. Скачивайте .NET 5 Preview 1. Попробуйте включить эту функцию. Что-нибудь сломается, в вашем коде, или в другой библиотеке, или в самом .NET. Или вы увидите значительные изменения в производительности, такие как пропускная способность или задержка, или рабочий набор, или что-то еще интересное. Обратите внимание, что изменение касается только асинхронных методов async ValueTask и async ValueTask<TResult>, поэтому, если у вас есть async Task или async Task<TResult>, вам также может потребоваться сначала изменить их, чтобы использовать их эквиваленты ValueTask.

Выпуск dotnet / runtime # 13633 отбражает виденье того, что мы должны делать с этой функцией для .NET 5, и Microsoft хочет услышать ваш фидбек; команда будет рада, если вы опубликуете какие-либо мысли или результаты.


Источник



Exception: Object reference not set to an instance of an object.
Posted on 18. March 2020

Анонс Entity Framework Core 5.0

https://devblogs.microsoft.com/dotnet/announcing-entity-framework-core-5-0-preview-1/

Microsoft объявила о первом анонсе EF Core 5.0.

Предпосылки

Для предварительного просмотра EF Core 5.0 требуется .NET Standard 2.1. Это означает:

• EF Core 5.0 работает на .NET Core 3.1; это не требует .NET 5.

○ Это может измениться в будущих превью в зависимости от того, как будет развиваться план для .NET 5.

EF Core 5.0 работает на других платформах, поддерживающих .NET Standard 2.1.

EF Core 5.0 не будет работать на платформах .NET Standard 2.0, включая .NET Framework.

Как скачать EF Core 5.0?

EF Core распространяется исключительно как набор пакетов NuGet. Например, чтобы добавить поставщика SQL Server в свой проект, вы можете использовать следующую команду с помощью инструмента dotnet:

dotnet add package Microsoft.EntityFrameworkCore.SqlServer --version 5.0.0-preview.2.20120.8

 

Пакеты EF Core, опубликованные сегодня:

Microsoft.EntityFrameworkCore - основной пакет EF Core

Microsoft.EntityFrameworkCore.SqlServer - поставщик базы данных для Microsoft SQL Server и SQL Azure

Microsoft.EntityFrameworkCore.Sqlite - поставщик базы данных для SQLite

Microsoft.EntityFrameworkCore.Cosmos - поставщик базы данных для Azure Cosmos DB

Microsoft.EntityFrameworkCore.InMemory - поставщик базы данных в памяти

Microsoft.EntityFrameworkCore.Tools - команды EF Core PowerShell для консоли диспетчера пакетов Visual Studio

Microsoft.EntityFrameworkCore.Design - общие компоненты времени разработки для инструментов EF Core

Microsoft.EntityFrameworkCore.SqlServer.NetTopologySuite - поддержка SQL Server для пространственных типов

Microsoft.EntityFrameworkCore.Sqlite.NetTopologySuite - поддержка SQLite для пространственных типов

Microsoft.EntityFrameworkCore.Proxies - загрузка и отслеживание изменений прокси

Microsoft.EntityFrameworkCore.Abstractions - разделенные EF Core абстракции

Microsoft.EntityFrameworkCore.Relational - общие компоненты EF Core для поставщиков реляционных баз данных

Microsoft.EntityFrameworkCore.Analyzers - анализаторы C # для EF Core

Microsoft.EntityFrameworkCore.Sqlite.Core - поставщик базы данных для SQLite без упакованного собственного двоичного файла

Microsoft опубликовали анонс о Framework Core 5.0 от  поставщика ADO.NET Microsoft.Data.Sqlite.Core.

Установка dotnet ef

Как и в случае EF Core 3.0 и 3.1, инструмент командной строки dotnet ef больше не включается в .NET Core SDK. Прежде чем вы сможете выполнить команды переноса EF Core или создания лесов, вам необходимо установить этот пакет как глобальный или локальный инструмент.

Чтобы установить инструмент предварительного просмотра глобально, сначала удалите любую существующую версию с помощью:

dotnet tool uninstall --global dotnet-ef

 

Затем установите с помощью:

dotnet tool install --global dotnet-ef --version 5.0.0-preview.2.20120.8

Эту новую версию dotnet ef можно использовать с проектами, в которых используются более старые версии среды выполнения EF Core.

Номера версий пакетов

В процессе сборки .NET 5 произошла ошибка, в результате которой пакеты EF preview 1 были ошибочно помечены как «5.0.0-preview.2.20120.8».

Это не должно иметь никакого функционального воздействия и не должно повлиять на Preview 2, который все еще запланирован на конец года.

Что нового в EF Core 5 Preview 1

Microsoft поддерживаем документацию новых функциях, представленных в каждом предварительном просмотре.

Некоторые из основных моментов из предварительного просмотра 1 вызываются ниже.

Простая регистрация

Эта опция функционально похожа на Database.Log в EF6. Таким образом, он предоставляет простой способ получения журналов из EF Core без необходимости настройки какого-либо внешнего каркаса ведения журналов.

EF Core заменяет Database.Log методом LogTo, вызываемым для DbContextOptionsBuilder в AddDbContext или OnConfiguring. Например:

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    => optionsBuilder.LogTo(Console.WriteLine);

 

Существуют перегрузки для:

• Установите минимальный уровень журнала

Пример: .LogTo(Console.WriteLine, LogLevel.Information)

• Фильтр только для определенных событий

Пример: .LogTo(Console.WriteLine, new[] {CoreEventId.ContextInitialized, RelationalEventId.CommandExecuted})

• Фильтр для всех событий в определенных категориях:

Пример: .LogTo(Console.WriteLine, new[] {DbLoggerCategory.Database.Name}, LogLevel.Information)

• Используйте пользовательский фильтр по событию и уровню:

Пример: .LogTo(Console.WriteLine, (id, level) => id == RelationalEventId.CommandExecuting)

 

Формат вывода может быть минимально сконфигурирован (API постоянно меняется), но вывод по умолчанию выглядит примерно так:

warn: 12/5/2019 09:57:47.574 CoreEventId.SensitiveDataLoggingEnabledWarning[10400] (Microsoft.EntityFrameworkCore.Infrastructure)
      Sensitive data logging is enabled. Log entries and exception messages may include sensitive application data, this mode should only be enabled during development.
dbug: 12/5/2019 09:57:47.581 CoreEventId.ShadowPropertyCreated[10600] (Microsoft.EntityFrameworkCore.Model.Validation)
      The property 'BlogId' on entity type 'Post' was created in shadow state because there are no eligible CLR members with a matching name.
info: 12/5/2019 09:57:47.618 CoreEventId.ContextInitialized[10403] (Microsoft.EntityFrameworkCore.Infrastructure)
      Entity Framework Core 5.0.0-dev initialized 'BloggingContext' using provider 'Microsoft.EntityFrameworkCore.SqlServer' with options: SensitiveDataLoggingEnabled
dbug: 12/5/2019 09:57:47.644 CoreEventId.ValueGenerated[10808] (Microsoft.EntityFrameworkCore.ChangeTracking)
      'BloggingContext' generated temporary value '-2147482647' for the 'Id' property of new 'Blog' entity.
...

 

Простой способ получить сгенерированный SQL

В EF Core 5.0 представлен метод расширения ToQueryString, который будет возвращать SQL, который EF Core сгенерирует при выполнении запроса LINQ. Например, код:

var query = context.Set&lt;customer>().Where(c => c.City == city);
Console.WriteLine(query.ToQueryString())

приводит к таким выводам при использовании поставщика базы данных SQL Server:

DECLARE p0 nvarchar(4000) = N'London';
 
SELECT [c].[CustomerID], [c].[Address], [c].[City], [c].[CompanyName], [c].[ContactName], [c].[ContactTitle], [c].[Country], [c].[Fax], [c].[Phone], [c].[PostalCode], [c].[Region]
FROM [Customers] AS [c]
WHERE [c].[City] = @__city_0

 

Обратите внимание, что объявления для параметров правильного типа также включены в вывод. Это позволяет копировать / вставлять в SQL Server Management Studio или аналогичные инструменты, так что запрос может быть выполнен для отладки / анализа.

Используйте атрибут C #, чтобы указать, что у объекта нет ключа

Тип объекта теперь можно настроить как “не имеющий ключа”, используя новый KeylessAttribute. Например:

[Keyless]
public class Address
{
    public string Street { get; set; }
    public string City { get; set; }
    public int Zip { get; set; }
}

 

Соединение или строка соединения могут быть изменены при инициализации DbContext

Теперь проще создать экземпляр DbContext без какого-либо соединения или строки соединения. Кроме того, соединение или строка соединения теперь могут быть изменены в экземпляре контекста. Это позволяет одному и тому же экземпляру контекста динамически подключаться к разным базам данных.

Прокси отслеживания изменений

EF Core теперь может генерировать прокси во время выполнения, которые автоматически реализуют INotifyPropertyChanging и  INotifyPropertyChanged. Затем они сообщают об изменениях значений свойств сущностей непосредственно в EF Core, избегая необходимости сканировать изменения. Однако прокси-серверы имеют свои собственные ограничения, поэтому они не для всех.

Расширенные представления отладки

Представления отладки - это простой способ взглянуть на внутренности EF Core при отладке проблем. Представление отладки для Модели было реализовано. Для EF Core 5.0 Microsoft  также упростили представление модели и добавили новое представление отладки для отслеживаемых объектов в диспетчере состояний.

Модель отладки

Разверните свойство Model объекта DbContext в выбранном отладчике и раскройте свойство DebugView.

LongView - это вид модели, который у нас был в течение некоторого времени. ShortView является новым и не включает аннотации моделей, которые значительно облегчают чтение. Например, вот одна из наших тестовых моделей:

Model:

  EntityType: Chassis

    Properties:

      TeamId (int) Required PK FK AfterSave:Throw

      Name (string)

      Version (no field, byte[]) Shadow Concurrency BeforeSave:Ignore AfterSave:Ignore ValueGenerated.OnAddOrUpdate

    Navigations:

      Team (_team, Team) ToPrincipal Team Inverse: Chassis PropertyAccessMode.Field

    Keys:

      TeamId PK

    Foreign keys:

      Chassis {'TeamId'} -> Team {'Id'} Unique ToDependent: Chassis ToPrincipal: Team

  EntityType: Driver

    Properties:

      Id (int) Required PK AfterSave:Throw ValueGenerated.OnAdd

      CarNumber (Nullable<int>)

      Championships (int) Required

      Discriminator (no field, string) Shadow Required

      FastestLaps (int) Required

      Name (string)

      Podiums (int) Required

      Poles (int) Required

      Races (int) Required

      TeamId (int) Required FK Index

      Version (no field, byte[]) Shadow Concurrency BeforeSave:Ignore AfterSave:Ignore ValueGenerated.OnAddOrUpdate

      Wins (int) Required

    Navigations:

      Team (_team, Team) ToPrincipal Team Inverse: Drivers PropertyAccessMode.Field

    Keys:

      Id PK

    Foreign keys:

      Driver {'TeamId'} -> Team {'Id'} ToDependent: Drivers ToPrincipal: Team

    Indexes:

      TeamId

  EntityType: Engine

    Properties:

      Id (int) Required PK AfterSave:Throw ValueGenerated.OnAdd

      EngineSupplierId (int) Required FK Index Concurrency

      Name (string) Concurrency

    Navigations:

      EngineSupplier (_engineSupplier, EngineSupplier) ToPrincipal EngineSupplier Inverse: Engines PropertyAccessMode.Field

      Gearboxes (_gearboxes, ICollection<gearbox>) Collection ToDependent Gearbox PropertyAccessMode.Field

      StorageLocation (Location) ToDependent Location PropertyAccessMode.Field

      Teams (_teams, ICollection<team>) Collection ToDependent Team Inverse: Engine PropertyAccessMode.Field

    Keys:

      Id PK

    Foreign keys:

      Engine {'EngineSupplierId'} -> EngineSupplier {'Id'} ToDependent: Engines ToPrincipal: EngineSupplier

    Indexes:

      EngineSupplierId

  EntityType: EngineSupplier

    Properties:

      Id (int) Required PK AfterSave:Throw ValueGenerated.OnAdd

      Name (string)

    Navigations:

      Engines (_engines, ICollection<engine>) Collection ToDependent Engine Inverse: EngineSupplier PropertyAccessMode.Field

    Keys:

      Id PK

  EntityType: Gearbox

    Properties:

      Id (int) Required PK AfterSave:Throw ValueGenerated.OnAdd

      EngineId (no field, Nullable<int>) Shadow FK Index

      Name (string)

    Keys:

      Id PK

    Foreign keys:

      Gearbox {'EngineId'} -> Engine {'Id'} ToDependent: Gearboxes

    Indexes:

      EngineId

  EntityType: Location

    Properties:

      EngineId (no field, int) Shadow Required PK FK AfterSave:Throw ValueGenerated.OnAdd

      Latitude (double) Required Concurrency

      Longitude (double) Required Concurrency

    Keys:

      EngineId PK

    Foreign keys:

      Location {'EngineId'} -> Engine {'Id'} Unique Ownership ToDependent: StorageLocation

  EntityType: Sponsor

    Properties:

      Id (int) Required PK AfterSave:Throw ValueGenerated.OnAdd

      ClientToken (no field, Nullable</int><int>) Shadow Concurrency

      Discriminator (no field, string) Shadow Required

      Name (string)

      Version (no field, byte[]) Shadow Concurrency BeforeSave:Ignore AfterSave:Ignore ValueGenerated.OnAddOrUpdate

    Keys:

      Id PK

  EntityType: SponsorDetails

    Properties:

      TitleSponsorId (no field, int) Shadow Required PK FK AfterSave:Throw ValueGenerated.OnAdd

      ClientToken (no field, Nullable</int><int>) Shadow Concurrency

      Days (int) Required

      Space (decimal) Required

      Version (no field, byte[]) Shadow Concurrency BeforeSave:Ignore AfterSave:Ignore ValueGenerated.OnAddOrUpdate

    Keys:

      TitleSponsorId PK

    Foreign keys:

      SponsorDetails {'TitleSponsorId'} -> TitleSponsor {'Id'} Unique Ownership ToDependent: Details

  EntityType: Team

    Properties:

      Id (int) Required PK AfterSave:Throw

      Constructor (string)

      ConstructorsChampionships (int) Required

      DriversChampionships (int) Required

      EngineId (no field, Nullable</int><int>) Shadow FK Index

      FastestLaps (int) Required

      GearboxId (Nullable</int><int>) FK Index

      Name (string)

      Poles (int) Required

      Principal (string)

      Races (int) Required

      Tire (string)

      Version (no field, byte[]) Shadow Concurrency BeforeSave:Ignore AfterSave:Ignore ValueGenerated.OnAddOrUpdate

      Victories (int) Required

    Navigations:

      Chassis (_chassis, Chassis) ToDependent Chassis Inverse: Team PropertyAccessMode.Field

      Drivers (_drivers, ICollection<driver>) Collection ToDependent Driver Inverse: Team PropertyAccessMode.Field

      Engine (_engine, Engine) ToPrincipal Engine Inverse: Teams PropertyAccessMode.Field

      Gearbox (_gearbox, Gearbox) ToPrincipal Gearbox PropertyAccessMode.Field

    Keys:

      Id PK

    Foreign keys:

      Team {'EngineId'} -> Engine {'Id'} ToDependent: Teams ToPrincipal: Engine

      Team {'GearboxId'} -> Gearbox {'Id'} Unique ToPrincipal: Gearbox

    Indexes:

      EngineId

      GearboxId Unique

  EntityType: TestDriver Base: Driver

  EntityType: TitleSponsor Base: Sponsor

    Navigations:

      Details (_details, SponsorDetails) ToDependent SponsorDetails PropertyAccessMode.Field

 

Менеджер “debug view

Состояние менеджера немного скрыто, чем модель. Чтобы найти его, перейдите в свойство ChangeTracker объекта DbContext в выбранном вами отладчике, а затем посмотрите в свойстве StateManager  и разверните DebugView.

Краткий обзор менеджера отображает:

• Каждый объект отслеживается

• Значение первичного ключа

• Состояние объекта: добавлено, не изменено, изменено или удалено.

• Значения свойства внешнего ключа

Например:

Engine (Shared) {Id: 1} Unchanged FK {EngineSupplierId: 1}
Location (Shared) {EngineId: 1} Unchanged FK {EngineId: 1}
Team (Shared) {Id: 4} Modified FK {EngineId: 1} FK {GearboxId: <null>}

 

Длинный вид показывает все в коротком виде:

• Текущее значение каждого свойства

• Независимо от того, помечено ли свойство как измененное

• Исходное значение свойства, если оно отличается от текущего значения

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

• Список объектов, на которые ссылается навигация по коллекции, снова используя значения первичного ключа

Например:

Engine (Shared) {Id: 1} Unchanged
  Id: 1 PK
  EngineSupplierId: 1 FK
  Name: 'FO 108X'
  EngineSupplier: <null>
  Gearboxes: </null><null>
  StorageLocation: {EngineId: 1}
  Teams: [{Id: 4}]
Location (Shared) {EngineId: 1} Unchanged
  EngineId: 1 PK FK
  Latitude: 47.64491
  Longitude: -122.128101
Team (Shared) {Id: 4} Modified
  Id: 4 PK
  Constructor: 'Ferrari'
  ConstructorsChampionships: 16
  DriversChampionships: 15
  EngineId: 1 FK Modified Originally 3
  FastestLaps: 221
  GearboxId: </null><null> FK
  Name: 'Scuderia Ferrari Marlboro'
  Poles: 203
  Principal: 'Stefano Domenicali'
  Races: 805
  Tire: 'Bridgestone'
  Version: '0x000000000001405A'
  Victories: 212
  Chassis: </null><null>
  Drivers: []
  Engine: {Id: 1}
  Gearbox: </null><null>

 

Улучшена обработка нулевой семантики базы данных

Реляционные базы данных обычно обрабатывают NULL как неизвестное значение и, следовательно, не равны никаким другим NULL. C #, с другой стороны, рассматривает нулл как определенное значение, которое сравнивается с любым другим нулл. EF Core по умолчанию переводит запросы так, чтобы они использовали нулевую семантику C #. EF Core 5.0 значительно повышает эффективность этих переводов.

Свойства индексатора

EF Core 5.0 поддерживает отображение свойств индексатора C #. Это позволяет подразделениям действовать как пакеты свойств, в которых столбцы сопоставляются с именованными свойствами в пакете.

Генерация проверочных ограничений для отображений enum

Миграции EF Core 5.0 теперь могут генерировать ограничения CHECK для сопоставлений свойств перечисления. Например:

EnumColumn VARCHAR(10) NOT NULL CHECK (MyEnumColumn IN('Useful', 'Useless', 'Unknown'))

 

IsRelational

Новый метод IsRelational был добавлен в дополнение к существующим IsSqlServerIsSqlite и IsInMemory.

Это можно использовать для проверки, использует ли DbContext какой-либо поставщик реляционных баз данных. Например:

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    if (Database.IsRelational())
    {
        // Do relational-specific model configuration.
    }
}

 

Советующая поддержка  Cosmos с ETags

Поставщик базы данных Azure Cosmos DB теперь поддерживает ETags. Используйте конструктор моделей в OnModelCreating для настройки ETag:

builder.Entity&lt;customer>().Property(c => c.ETag).IsEtagConcurrency();

 

Затем SaveChanges генерирует исключение DbUpdateConcurrencyException при конфликте параллелизма, который может быть обработан для реализации повторных попыток и т. Д.

Как запросить переводы для большего количества конструкций DateTime?

Запросы, содержащие новую конструкцию DateTime, теперь переведены.

Кроме того, теперь сопоставлены следующие функции SQL Server: * DateDiffWeek * DateFromParts

Например:

var count = context.Orders.Count(c => date > EF.Functions.DateFromParts(DateTime.Now.Year, 12, 25));

 

Перевод запросов для большего количества массива байтов

Запросы, использующие свойства Contains, Length, SequenceEqual и т. Д. В byte [], теперь переводятся в SQL. Например:

var blogs = context.Blogs.Where(e => e.Picture.Contains((byte)127)).ToList();

 

Перевод запроса для реверса

Запросы с использованием Reverse теперь переведены. Например:

context.Employees.OrderBy(e => e.EmployeeID).Reverse()

 

Запрос для битовых операторов

Запросы с использованием битовых операторов теперь транслируются в большем количестве случаев. Например:

context.Orders.Where(o => ~o.OrderID == negatedId)

 

Перевод запроса на строки в Cosmos

Запросы, использующие строковые методы Contains, StartsWith и EndsWith, теперь переводятся при использовании поставщика Azure Cosmos DB.

Ежедневные сборки

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

Как и в случае предварительного просмотра, для ежедневных сборок не требуется .NET 5; их можно использовать с GA / RTM-версией .NET Core 3.1.

Документация и отзывы

Отправной точкой для всей документации EF Core является docs.microsoft.com/ef/core/.

Пожалуйста, сообщайте о найденных проблемах и любые другие отзывы dotnet/efcore GitHub repo.

Спасибо команде!

Большое спасибо команде EF всем, кто использовал EF на протяжении многих лет!

Спасибо авторам!

Большое спасибо следующим членам сообщества, которые уже предоставили код или документацию для выпуска EF Core 5!


 

Источник



Exception: Object reference not set to an instance of an object.
Posted on 17. January 2020

Получение и анализ дампов памяти

Опираясь на улучшения диагностики, представленные в .NET Core 3.1, мы представили новый инструмент для сбора дампов кучи из запущенного процесса .NET Core.

В предыдущем посте мы представили dotnet-dump, инструмент, позволяющий вам собирать и анализировать дампы процессов. С тех пор мы усердно работали над улучшением работы с дампами.

Два ключевых улучшения, которые мы внесли в dotnet-dump:

Нам больше не требуется sudo  для сбора дампов в Linux

dotnet dump analyze теперь поддерживается в Windows

GC дампы

Однако одно из ключевых ограничений, которое остается, - это то, что дампы процессов не переносимы. Невозможно диагностировать дампы, собранные в Linux с помощью Windows и наоборот.

Многие распространенные сценарии не требуют полной проверки дампа процесса. Чтобы включить эти сценарии, мы представили новый облегченный механизм сбора дампа, который является переносимым. Запустив сборку мусора в целевом процессе, мы можем осуществлять потоковую передачу событий, генерируемых сборщиком мусора, через механизм Existing EventPipe для восстановления графика корней объектов из этих событий.

Эти дампы GC полезны для нескольких сценариев, включая:

Сравнение количества объектов по типу в куче

Анализ корней объекта

Нахождение каких объектов имеет ссылку на какой тип

Другой статистический анализ об объектах в куче

dotnet-gcdump

 

В .NET Core 3.1 мы представляем новый инструмент, который позволяет вам захватывать вышеупомянутые дампы процессов для анализа в PerfView и Visual Studio.

Вы можете установить этот глобальный инструмент .NET, выполнив следующую команду:

dotnet tool install --global dotnet-gcdump

 

Установив dotnet gcdump, вы можете перехватить дамп GC, выполнив следующую команду:

dotnet gcdump collect -p <target-process-PID>

 

Примечание: Сбор gcdump запускает полную сборку мусора Gen 2 в целевом процессе и может изменить характеристики производительности вашего приложения. Продолжительность паузы GC, испытываемая приложением, пропорциональна размеру кучи GC; приложения с большими кучами будут испытывать более длительные паузы.

Полученный файл.gcdump можно проанализировать в Visual Studio и PerfView в Windows.

Анализ дампов GC в Visual Studio

Собранные дампы GC можно проанализировать, открыв файлы .gcdumpв Visual Studio. После открытия в Visual Studio вы попадаете на страницу отчета об анализе памяти.

В верхней панели отображается количество и размер типов в снимке, включая размер всех объектов, на которые ссылается тип (Inclusive Size).

В нижней панели дерево Paths to Root отображает объекты, которые ссылаются на тип, выбранный в верхней панели. В дереве ссылочных типов отображаются ссылки, содержащиеся в типе, выбранном в верхней панели.

В дополнение к отчету об анализе памяти только одного дампа GC, Visual Studio также позволяет сравнивать два дампа GC. Чтобы просмотреть подробную информацию о разнице между текущим снимком и предыдущим снимком, перейдите в раздел отчета Compare To и выберите другой дамп GC, который будет использоваться в качестве базовой линии.

Заключение

Спасибо за опробование новых инструментов диагностики в .NET Core 3.1. Пожалуйста, продолжайте оставлять свои отзывы, либо в комментариях, либо на GitHub Мы внимательно прислушиваемся к вашим отзывам и будем вносить изменения.

 

Источник



Exception: Object reference not set to an instance of an object.
Posted on 14. December 2019

ConfigureAwait FAQ

.NET добавил async/await к языкам и библиотекам более семи лет назад. В то же время он завоевал популярность не только в экосистеме .NET, но и во множестве других языков и фреймворков. Также было замечено множество улучшений в .NET с точки зрения дополнительных языковых конструкций, использующих асинхронность, API-интерфейсов, предлагающих асинхронную поддержку, и фундаментальных улучшений в инфраструктуре, которые делают async/await (в частности, конкретное исполнение и улучшение диагностики в .NET).

Однако один из аспектов async/await, который продолжает вызывать вопросы, - это ConfigureAwait. Эта статья послужит общей информацией и списком часто задаваемых вопросов, которые можно использовать в качестве справочного материала в будущем. 

Чтобы действительно понять ConfigureAwait, нам нужно начать немного раньше ...

Что такое SynchronizationContext?

 System.Threading.SynchronizationContext docs утверждают, что он «обеспечивает основные функциональные возможности для распространения контекста синхронизации в различных моделях синхронизации». Не совсем очевидное описание.

В 99,9% случав использования SynchronizationContext - это просто тип, который предоставляющий виртуальный метод Post, который делегирует асинхронное выполнение (существует множество других виртуальных членов в SynchronizationContext, (они менее используемые). Post базового типа, буквально вызывает ThreadPool.QueueUserWorkItem для асинхронного вызова предоставленного делегата. Однако производные типы переопределяют Post, чтобы разрешить выполнение этого делегата в наиболее подходящем месте и в наиболее подходящее время.

Например, Windows Forms имеет производный от SynchronizationContext тип, который переопределяет Post, чтобы сделать эквивалент Control.BeginInvoke; это означает, что делегат будет вызван в какой-то более поздний момент в потоке, связанном с этим соответствующим элементом управления, иначе говоря, «the UI thread». Windows Forms полагается на обработку сообщений Win32 и имеет «message loop», работающий в потоке пользовательского интерфейса, который просто ожидает поступления новых сообщений для обработки. Эти сообщения могут быть для движений и щелчков мыши, для ввода с клавиатуры, для системных событий, для делегатов, доступных для вызова и т. Д. Таким образом, с учетом экземпляра SynchronizationContext для потока пользовательского интерфейса приложений Windows Forms, чтобы получить делегата для выполнения на этот поток пользовательского интерфейса, просто нужно передать его в Post.

То же самое касается Windows Presentation Foundation (WPF). Он имеет свой собственный производный от SynchronizationContext тип с переопределением Post, которое аналогично «marshals» делегат в потоке пользовательского интерфейса (через Dispatcher.BeginInvoke), в данном случае управляемый диспетчером WPF, а не элементом управления Windows Forms.

И для Windows RunTime (WinRT). Он имеет свой собственный производный от SynchronizationContext тип с переопределением Post, который также ставит делегата в очередь потока пользовательского интерфейса через его CoreDispatcher.

Это выходит за рамки простого «run this delegate on the UI thread». Любой может реализовать SynchronizationContext с Post, который делает все что угодно. Например, мне может быть все равно, в каком потоке работает делегат, но я хочу убедиться, что все делегаты Post моего SynchronizationContext выполняются с некоторой ограниченной степенью параллелизма. Я могу добиться этого с помощью специального SynchronizationContext, например:

Фактически, среда модульного тестирования xunit предоставляет SynchronizationContext, очень похожий на этот, который он использует для ограничения объема кода, связанного с тестами, которые могут выполняться одновременно.

Преимущество является в том, что, как и с любой абстракцией: он предоставляет единый API, который можно использовать для постановки в очередь делегата для обработки, как этого захочет создатель реализации. Итак, если я пишу библиотеку, и я хочу уйти и выполнить некоторую работу, а затем поставить делегата в очередь обратно в «context» исходного местоположения, мне просто нужно взять их SynchronizationContext, удержать его, а затем когда закончите свою работу, вызовите Post в этом контексте, чтобы передать делегата. Мне не нужно знать, что для Windows Forms я должен взять Control  и использовать его BeginInvoke, или для WPF я должен взять Dispatcher  и использовать его BeginInvoke, или для xunit я должен каким-то образом получить его контекст и очередь к нему; Мне просто нужно взять текущий SynchronizationContext  и использовать его позже. Чтобы достичь этого, SynchronizationContext  предоставляет свойство Current, так что для достижения вышеупомянутой цели я мог бы написать такой код:

Фреймворк, который хочет предоставить пользовательский контекст из Current , использует метод SynchronizationContext.SetSynchronizationContext.

Что такое TaskScheduler?

Synchronization Context - это общая абстракция для «scheduler». Отдельные структуры иногда имеют свои собственные абстракции для планировщика, и System.Threading.Tasks не является исключением. Когда задачи поддерживаются делегатом, так что они могут быть поставлены в очередь и выполнены, они связаны с System.Threading.Tasks.TaskScheduler. Так же, как SynchronizationContext предоставляет виртуальный метод Post для постановки в очередь вызова делегата (с реализацией, позже вызывающей делегат через типичные механизмы вызова делегата), TaskScheduler  предоставляет абстрактный метод QueueTask  (с реализацией, позже вызывающей эту задачу через метод ExecuteTask ).

Планировщик по умолчанию, возвращаемый TaskScheduler.Default, является пулом потоков, но его можно извлечь из TaskScheduler и переопределить соответствующие методы для достижения произвольного поведения, когда и где вызывается Task. Например, основные библиотеки включают

Тип System.Threading.Tasks.ConcurrentExclusiveSchedulerPair. Экземпляр этого класса предоставляет два свойства TaskScheduler, одно из которых называется ExclusiveScheduler , а другое - ConcurrentScheduler. Задачи, запланированные для ConcurrentScheduler , могут выполняться одновременно, но при условии ограничения, предоставленного ConcurrentExclusiveSchedulerPair при его создании (аналогично MaxConcurrencySynchronizationContext , показанного ранее), и никакие задачи ConcurrentScheduler  не будут выполняться, когда выполняется задача, запланированная для ExclusiveScheduler.

Как и SynchronizationContext, TaskScheduler также имеет свойство Current, которое возвращает «current» TaskScheduler. Однако, в отличие от SynchronizationContext, здесь нет способа настроить текущего планировщика. Вместо этого текущий планировщик - тот, который связан с текущей выполняющимся Task, и планировщик предоставляется системе как часть запуска Task. Так, например, эта программа выведет «True», так как лямбда, используемая с StartNew , выполняется в ConcurrentExclusiveSchedulerPair ExclusiveScheduler и увидит TaskScheduler.Current, установленный в этот планировщик:

Интересно, что TaskScheduler предоставляет статический метод FromCurrentSynchronizationContext, который создает новый TaskScheduler, который ставит в очередь Task для выполнения на любом возвращаемом SynchronizationContext.Current, используя метод Post  для постановки в очередь задач.

Как SynchronizationContext и TaskScheduler связаны с ожиданием?

Подумайте о написании приложения UI с помощью Button. П Нажав на Button, мы хотим загрузить текст с веб-сайта и установить его в качестве Button Content. Доступ к Button возможен только из потока   UI, которому она принадлежит, когда мы успешно загрузили новый период, временный текст и хотим сохранить его обратно в ButtonContent нам нужно сделать это из потока, которому принадлежит элемент управления. Если мы этого не сделаем, мы получим отклонение, например:

System.InvalidOperationException: 'The calling thread cannot access this object because a different thread owns it.'

 

Если бы мы писали это вручную, мы могли бы использовать SynchronizationContext, как показано ранее, чтобы перенаправить настройку Content обратно в исходный контекст, например через TaskScheduler:

private static readonly HttpClient s_httpClient = new HttpClient();
 
private void downloadBtn_Click(object sender, RoutedEventArgs e)
{
    s_httpClient.GetStringAsync("http://example.com/currenttime").ContinueWith(downloadTask =>
    {
        downloadBtn.Content = downloadTask.Result;
    }, TaskScheduler.FromCurrentSynchronizationContext());
}

 

или используя SynchronizationContext напрямую:

private static readonly HttpClient s_httpClient = new HttpClient();
 
private void downloadBtn_Click(object sender, RoutedEventArgs e)
{
    SynchronizationContext sc = SynchronizationContext.Current;
    s_httpClient.GetStringAsync("http://example.com/currenttime").ContinueWith(downloadTask =>
    {
        sc.Post(delegate
        {
            downloadBtn.Content = downloadTask.Result;
        }, null);
    });
}

 

Оба этих подхода, тем не менее, явно используют обратные вызовы. Вместо этого мы хотели бы написать код естественным образом с помощью async/await:

private static readonly HttpClient s_httpClient = new HttpClient();
 
private async void downloadBtn_Click(object sender, RoutedEventArgs e)
{
    string text = await s_httpClient.GetStringAsync("http://example.com/currenttime");
    downloadBtn.Content = text;
}

 

Это «просто работает», при успешной установке Content в потоке UI, потому что, как и в случае с ручной реализованной версией, await Task по умолчанию обращает внимание на SynchronizationContext.Current, а также  TaskScheduler.Current Когда вы await чего-либо в C #, компилятор преобразует код для запроса (посредством вызова GetAwaiter) «ожидаемого» (в данном случае, Task) для «ожидающего» (в данном случае TaskAwaiter<string>). Этот ожидающий отвечает за подключение обратного вызова (часто называемого «продолжением»), который будет вызывать обратный вызов в конечный автомат после завершения ожидаемого объекта, и он делает это с использованием любого контекста / планировщика, захваченного во время обратного вызова. Хотя не совсем используемый код (используются дополнительные оптимизации и настройки), он выглядит примерно так:

object scheduler = SynchronizationContext.Current;
if (scheduler is null && TaskScheduler.Current != TaskScheduler.Default)
{
    scheduler = TaskScheduler.Current;
}

 

Другими словами, он сначала проверяет, установлен ли SynchronizationContext, если его нету, независимо от запуска TaskScheduler выполняется по умолчанию. Если он сочтет, что обратный вызов готов к запуску он будет использовать фиксированнй планировщик; в противном случае он обычно выполняет обратный вызов как часть операции, завершающей ожидаемую задачу.

Что делает ConfigureAwait (false)?

Метод ConfigureAwait не является особенным: он не распознается каким-либо особым компилятором или средой выполнения. Это просто метод, который возвращает структуру (ConfiguredTaskAwaitable), которая возвращает исходную задачу, к которой она была вызвана, а также указанное логическое значение. Помните, что await может использоваться с любым типом, который выставляет правильный паттерн. Возвращая другой тип, это означает что когда компилятор получает доступ к методу GetAwaiter  (часть паттерна), он делает это вне типа, непосредственно из задачи.

В частности, ожидание типа, возвращенного из ConfigureAwait(continueOnCapturedContext: false) вместо ожидания Task, напрямую заканчивается воздействием на логику, показанную ранее для того, как захватывается целевой контекст / планировщик. Это эффективно делает ранее показанную логику более похожей на это:

object scheduler = null;
if (continueOnCapturedContext)
{
    scheduler = SynchronizationContext.Current;
    if (scheduler is null && TaskScheduler.Current != TaskScheduler.Default)
    {
        scheduler = TaskScheduler.Current;
    }
}

 

Другими словами, указав значение false, даже если существует текущий контекст или планировщик для обратного вызова, он делает вид, что его нет.

Почему нужно использовать ConfigureAwait (false)?

ConfigureAwait(continueOnCapturedContext: false) используется, чтобы не вызывать обратный вызов в исходном контексте или планировщике. Это имеет несколько преимуществ:

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

 

Для очень срочных путей даже дополнительные затраты на проверку текущего  SynchronizationContext и текущего TaskScheduler (оба из которых включают в себя доступ к статическим потокам) могут добавить накладные расходы. Если код после await на самом деле не требует выполнения в исходном контексте, использование ConfigureAwait(false) может избежать всех этих затрат: его не нужно ставить в очередь, он может использовать все возможные оптимизации.

Как избежать тупиков. Рассмотрим библиотечный метод, который использует await в результате некоторой загрузки по сети. Вы вызываете этот метод и синхронно блокируете ожидание его завершения, например, с помощью .Wait()или .Result или .GetAwaiter().GetResult() выключить возвращенный объект Task.

  Теперь рассмотрим, что произойдет, если ваш вызов этого произойдет, если текущий SynchronizationContext ограничивает число операций, которые могут быть запущены на нем, до 1, будь то явно с помощью чего-то вроде MaxConcurrencySynchronizationContext, показанного ранее, или неявным образом из-за того, что это контекст, который только имеет одну нить, которую можно использовать, например, поток пользовательского интерфейса. Таким образом, вы вызываете метод в этом одном потоке, а затем блокируете его, ожидая завершения операции. Операция запускает загрузку по сети и ожидает ее. Так как ожидание Задачи по умолчанию захватывает текущий SynchronizationContext, он делает это, и когда загрузка по сети завершается, он помещает обратно в SynchronizationContext обратный вызов, который вызовет оставшуюся часть операции. Но единственный поток, который может обработать обратный вызов в очереди, в настоящее время заблокирован блокировкой кода, ожидающей завершения операции. И эта операция не завершится, пока не будет обработан обратный вызов. Тупик! Это может применяться, даже когда контекст не ограничивает параллелизм только 1, но когда ресурсы ограничены. Представьте себе ту же ситуацию, за исключением использования MaxConcurrencySynchronizationContext с лимитом 4. И вместо того, чтобы делать только один вызов операции, мы ставим в очередь в этот контекст 4 вызова, каждый из которых делает вызов и блокирует ожидание его завершения. Теперь мы все еще заблокировали все ресурсы в ожидании завершения асинхронных методов, и единственное, что позволит этим асинхронным методам завершиться, - это если их обратные вызовы могут быть обработаны этим контекстом, который уже полностью используется. Опять тупик! Если бы вместо этого метод библиотеки использовал ConfigureAwait(false), он не поставил бы в очередь обратный вызов обратно в исходный контекст, избегая сценариев взаимоблокировки.

Почему я использую ConfigureAwait (true)?

ConfigureAwait(true) не делает ничего значимого. При сравнении await task с await task.ConfigureAwait(true). ConfigureAwait (true) они функционально идентичны. Если вы видите ConfigureAwait(true) в рабочем коде, вы можете удалить его без вреда для себя.

Метод ConfigureAwait принимает логическое значение, поскольку существуют некоторые нишевые ситуации, в которых вы хотите передать переменную для управления конфигурацией. Но в 99% случаев используется жестко закодированное значение ложного аргумента ConfigureAwait(false).

В каких случаях использовать ConfigureAwait (false)?

Это зависит от того, реализуете ли вы код уровня приложения или код библиотеки общего назначения?

При написании приложений вы обычно хотите действий по умолчанию. Если модель / среда приложения (например, Windows Forms, WPF, ASP.NET Core и т. Д.) Публикует пользовательский SynchronizationContext, почти наверняка есть веская причина для этого: он предоставляет способ для кода, который заботится о контексте синхронизации, взаимодействовать с моделью приложения / среды соответственно. Поэтому, если вы пишете обработчик событий в приложении Windows Forms, пишете модульный тест в xunit, пишете код в контроллере ASP.NET MVC, независимо от того, действительно ли модель приложения опубликовала SynchronizationContext, вы хотите использовать SynchronizationContext, если он существует. А это означает, что по умолчанию / ConfigureAwait(true). Вы просто используете await, и правильное осуществление происходит в отношении обратных вызовов / продолжений, отправляемых обратно в исходный контекст, если таковой существует. Это приводит к общему руководству: если вы пишете код уровня приложения, не используйте ConfigureAwait(false). Если вы вспомните пример кода обработчика события Click ранее в этом посте:

private static readonly HttpClient s_httpClient = new HttpClient();
 
private async void downloadBtn_Click(object sender, RoutedEventArgs e)
{
    string text = await s_httpClient.GetStringAsync("http://example.com/currenttime");
    downloadBtn.Content = text;
}

 

установка downloadBtn.Content = text должна быть сделана обратно в исходном контексте. Если код нарушил это правило и вместо этого использовал ConfigureAwait(false) тогда он не должен иметь:

private static readonly HttpClient s_httpClient = new HttpClient();
 
private async void downloadBtn_Click(object sender, RoutedEventArgs e)
{
    string text = await s_httpClient.GetStringAsync("http://example.com/currenttime").ConfigureAwait(false); // bug
    downloadBtn.Content = text;
}

 

То же самое относится и к коду в классическом приложении ASP.NET, зависящем от HttpContext.Current; использование ConfigureAwait(false), а затем использования HttpContext.Current, вероятно, приведет к проблемам.

В отличие от этого, библиотеки общего назначения являются «универсальными» отчасти потому, что их не волнует среда, в которой они используются. Вы можете использовать их из веб-приложения, из клиентского приложения или из теста, это не имеет значения, поскольку код библиотеки не зависит от модели приложения, в которой он может быть использован. Быть независимым также означает, что он не собирается делать что-то, что должно взаимодействовать с моделью приложения определенным образом, например, он не будет получать доступ к элементам управления UI, потому что библиотека общего назначения ничего не знает об элементах управления UI. Поскольку тогда нам не нужно запускать код в какой-либо конкретной среде, мы можем избежать принудительного возврата продолжений / обратных вызовов к исходному контексту, и мы делаем это, используя ConfigureAwait(false) и получая преимущества как в производительности, так и в надежности. Это приводит к общему руководству: если вы пишете код библиотеки общего назначения, используйте ConfigureAwait(false). Вот почему, например, вы увидите каждое (или почти каждое) await в библиотеках среды выполнения .NET Core, использующее ConfigureAwait(false) в каждом await; за некоторыми исключениями, в случаях, когда это не очень вероятно, ошибка может быть исправлена. Например, этот PR исправил отсутствующий вызов ConfigureAwait(false) в HttpClient.

Как и в случае со всеми указаниями, конечно, могут быть исключения, места, где это не имеет смысла. Например, одно из более крупных исключений (или, по крайней мере, категорий, требующих обдумывания) в библиотеках общего назначения - это когда в этих библиотеках есть API, которые принимают делегатов для вызова. В таких случаях абонент библиотеки проходит потенциально код приложения на уровень, который будет вызван в библиотеке, которая затем эффективно делает это «общее назначение» предположение библиотеки. Рассмотрим, например, асинхронную версию метода Where LINQ, например  public static async IAsyncEnumerable<T> WhereAsync(this IAsyncEnumerable<T> source, Func<T, bool> predicate). Нужно ли здесь вызывать predicate в исходном SynchronizationContext вызывающей стороны? Это зависит от реализации WhereAsync, и по этой причине он может отказаться от использования ConfigureAwait(false).

Даже в этих особых случаях общее руководство стоит и является очень хорошей отправной точкой: используйте ConfigureAwait(false), если вы пишете код общего назначения для библиотеки / приложения-модели.

Гарантирует ли ConfigureAwait (false), что обратный вызов не будет выполняться в исходном контексте?

Нет. Это гарантирует, что он не будет поставлен в очередь в исходный контекст ... но это не означает, что код после await task.ConfigureAwait(false) по-прежнему не будет работать в исходном контексте. Это связано с тем, что ожидающие не заставляют что-либо возвращаться в очередь. Таким образом, если вы ожидаете задачу, которая уже выполнена к тому времени, независимо от того, использовали ли вы ConfigureAwait(false), код сразу после этого продолжит выполняться в текущем потоке в любом контексте.

Заметным исключением является то, что вы знаете, что первое await всегда завершается асинхронно, а ожидаемое событие вызывает свой обратный вызов в среде, свободной от пользовательского SynchronizationContext  или TaskScheduler. Например, CryptoStream  в библиотеках времени выполнения .NET хочет, чтобы его потенциально вычислительно-интенсивный код не выполнялся как часть синхронного вызова вызывающей стороны, чтобы все после первого await  выполнялось в потоке резерва. Однако даже в этом случае вы заметите, что в следующем await все еще используется ConfigureAwait(false); технически это не является необходимым, но это делает обзор кода намного проще, так как в противном случае каждый раз, когда этот код просматривается, он не требует анализа, чтобы понять, почему ConfigureAwait(false) был отключен.

 

Можно ли применять Task.Run, чтобы избежать использования ConfigureAwait (false)?

Да. Если вы напишите:

Task.Run(async delegate
{
    await SomethingAsync(); // won't see the original context

затем ConfigureAwait(false) для этого вызова SomethingAsync() будет nop, поскольку делегат, переданный в Task.Run, будет выполняться в потоке пула потоков без кода пользователя выше в стеке, например SynchronizationContext.Current вернет null. Кроме того,  Task.Run неявно использует TaskScheduler.Default, что означает, что запрос TaskScheduler.Current  внутри делегата также вернет  Default. Это означает, что ожидание будет демонстрировать одинаковое действия независимо от того, использовался ли ConfigureAwait(false). Он также не дает никаких гарантий относительно того, что может делать код внутри этой лямбды. Если у вас есть код:

Task.Run(async delegate
{
    SynchronizationContext.SetSynchronizationContext(new SomeCoolSyncCtx());
    await SomethingAsync(); // will target SomeCoolSyncCtx
});

 

код внутри SomethingAsync на самом деле увидит SynchronizationContext.Current как тот экземпляр SomeCoolSyncCtx, и это await , и любые ненастроенные задачи внутри SomethingAsync отправят обратно на него. Таким образом, чтобы использовать этот подход, вам необходимо понять, что весь код, который вы ставите в очередь, может или не может делать, и могут ли его действия помешать вашему.

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

Также имейте в виду, что такие уловки могут вызвать больше проблем, чем они стоят, и иметь другие непредвиденные последствия. Например, инструменты статического анализа (например, анализаторы Roslyn) были написаны для отметки ожидающих, которые не используют ConfigureAwait(false), таких как CA2007. Если вы включили такой анализатор, но затем применили хитрость, подобную этой, просто чтобы избежать использования ConfigureAwait, есть большая вероятность, что анализатор пометит его и фактически вызовет дополнительную работу для вас. Так что, возможно, вы затем отключите анализатор из-за его шумности, и теперь вы в конечном итоге пропустите другие места в кодовой базе, где вы на самом деле должны были использовать ConfigureAwait(false).

Можно ли использовать SynchronizationContext.SetSynchronizationContext, вместо ConfigureAwait (false)?

Это зависит от используемого кода.

Некоторые разработчики пишут такой код:

Task t;
SynchronizationContext old = SynchronizationContext.Current;
SynchronizationContext.SetSynchronizationContext(null);
try
{
    t = CallCodeThatUsesAwaitAsync(); // awaits in here won't see the original context
}
finally { SynchronizationContext.SetSynchronizationContext(old); }
await t; // will still target the original context

 

в надежде, что он сделает код внутри CallCodeThatUsesAwaitAsync, увидит текущий контекст как null. Однако вышеприведенное не повлияет на ожидаемый файл TaskScheduler.Current, поэтому, если этот код выполняется на каком-то пользовательском TaskScheduler, await  внутри CallCodeThatUsesAwaitAsync (и не использующий ConfigureAwait(false)) все равно увидит и вернется в очередь к этому пользовательскому TaskScheduler.

Все те же предостережения также применимы, как и в предыдущем FAQ, связанном с Task.Run: такие обходные пути имеют практические последствия, и код внутри попытки может также помешать, установив другой контекст (или вызвав код не по умолчанию TaskScheduler).

При таком шаблоне вы также должны быть осторожны с небольшим изменением:

SynchronizationContext old = SynchronizationContext.Current;
SynchronizationContext.SetSynchronizationContext(null);
try
{
    await t;
}
finally { SynchronizationContext.SetSynchronizationContext(old); }

 

Нет никакой гарантии, что ожидание закончится вызовом обратного вызова / продолжения в исходном потоке, что означает, что сброс SynchronizationContext обратно к исходному может фактически не произойти в исходном потоке, что может привести к тому, что последующие рабочие элементы в этом потоке будут видны в неправильном контексте (чтобы противостоять этому, хорошо написанные модели приложений, которые устанавливают пользовательский контекст, обычно добавляют код, чтобы сбросить его вручную перед вызовом любого другого пользовательского кода). И даже если он действительно работает в том же потоке, может пройти некоторое время, прежде чем он будет выполнен, так что контекст не будет должным образом восстановлен на некоторое время. И если он работает в другом потоке, это может привести к неправильному контексту в этом потоке. И так далее.

Использование GetAwaiter (). GetResult (). Нужно ли использовать ConfigureAwait (false)?

Нет. ConfigureAwait влияет только на обратные вызовы. В частности, шаблон ожидающего требует, чтобы ожидающие предоставили свойство IsCompleted, метод GetResult  и метод OnCompleted  (необязательно с методом UnsafeOnCompleted ). ConfigureAwait влияет только на поведение  {Unsafe}OnCompleted, поэтому, если вы просто напрямую вызываете GetResult(), независимо от того, делаете ли вы это с помощью TaskAwaiter  или ConfiguredTaskAwaitable.ConfiguredTaskAwaiter. Поэтому, если вы видите в коде task.ConfigureAwait(false). GetAwaiter().GetResult(), вы можете заменить его на task.GetAwaiter().GetResult()  (а также подумать, действительно ли вы хотите блокировать подобное).

Я знаю, что работаю в среде, в которой никогда не будет настраиваемого SynchronizationContext или настраиваемого TaskScheduler. Могу ли пропустить, использование ConfigureAwait (false)?

Как упоминалось в предыдущих часто задаваемых вопросах, то, что модель приложения, в которой вы работаете, не устанавливает настраиваемый SynchronizationContext и не вызывает ваш код в настраиваемом TaskScheduler, не означает, что какой-то другой пользовательский или библиотечный код этого не делает. Таким образом, вы должны быть уверены, что это не так, или, по крайней мере, учитывать риск.

Я слышал, что ConfigureAwait (false) больше не требуется в .NET Core. Правда?

Ложь. Он необходим при работе в .NET Core по тем же причинам, что и при работе в .NET Framework. В этом отношении ничего не изменилось.

Однако изменилось то, что публикуют определенные среды свой собственный SynchronizationContext. В частности, тогда как классический ASP.NET в .NET Framework имеет свой собственный SynchronizationContext, в отличие от ASP.NET Core нет. Это означает, что код, работающий в приложении ASP.NET Core по умолчанию, не увидит пользовательский SynchronizationContext, что уменьшает необходимость выполнения ConfigureAwait(false) в такой среде.

Однако это не означает, что пользовательский SynchronizationContext или TaskScheduler  никогда не будет представлен. Если какой-либо пользовательский код (или другой код библиотеки, используемый вашим приложением) устанавливает пользовательский контекст и вызывает ваш код или вызывает ваш код в Task, запланированной для пользовательского TaskScheduler, то даже в ASP.NET Core ваши ожидающие могут увидеть не контекст по умолчанию или планировщик, который заставит вас хотеть использовать ConfigureAwait(false). Конечно, в таких ситуациях, если вы избегаете синхронной блокировки (что вы должны избегать в веб-приложениях независимо от этого),  если вы не возражаете против небольших накладных расходов на производительность в таких ограниченных случаях, вы, вероятно, можете обойтись без использования ConfigureAwait(false).

Могу ли я использовать ConfigureAwait, когда ожидание по каждому элементу в IAsyncEnumerable?

Да. Посмотрите эту статью MSDN Magazine для примера.

await foreach привязывается к шаблону, и поэтому, хотя он может использоваться для перечисления IAsyncEnumerable<T>, он также может использоваться для перечисления чего-то, что предоставляет правильную площадь поверхности API. Библиотеки времени выполнения .NET включают метод расширения ConfigureAwait для IAsyncEnumerable<T>, который возвращает пользовательский тип, заключающий в себе IAsyncEnumerable<T> и Boolean, выставляет правильный шаблон. Когда компилятор генерирует вызовы методов MoveNextAsync и DisposeAsync, эти вызовы возвращаются к сконфигурированному типу структуры, и он, в свою очередь, выполняет ожидание желаемым сконфигурированным способом.

Могу ли я использовать ConfigureAwait, когда «ожидаю использования» IAsyncDisposable?

Да, хотя с небольшими сложностями.

Библиотеки времени выполнения .NET предоставляют метод расширения ConfigureAwait для IAsyncDisposable, и использование await using  будет успешно работать с этим, поскольку он реализует соответствующий шаблон (а именно, предоставляет соответствующий метод DisposeAsync ):

await using (var c = new MyAsyncDisposableClass().ConfigureAwait(false))
{
    ...
}

 

Проблема здесь в том, что тип теперь не MyAsyncDisposableClass, а скорее System.Runtime.CompilerServices.ConfiguredAsyncDisposable, который является типом, возвращаемым из этого метода расширения ConfigureAwait  в IAsyncDisposable.

Чтобы обойти это, вам нужно написать одну дополнительную строку:

var c = new MyAsyncDisposableClass();
await using (c.ConfigureAwait(false))
{
    ...
}

 

Теперь тип c снова является желаемым MyAsyncDisposableClass. Это также имеет эффект увеличения области действия c; если это эффективно, вы можете обернуть все это в фигурные скобки.

Я использовал ConfigureAwait (false), но AsyncLocal все еще передавался в код после ожидания. Это ошибка?

Нет, это ожидаемо. Данные AsyncLocal<T> передаются как часть ExecutionContext, которая отделена от SynchronizationContext. Если вы явно не отключили поток ExecutionContext с помощью ExecutionContext.SuppressFlow(), ExecutionContext (и, следовательно, данные AsyncLocal<T>) всегда будут проходить через await, независимо от того, используется ли ConfigureAwait , чтобы избежать захвата исходного SynchronizationContext. Для получения дополнительной информации см. Этот пост в блоге.

Может ли язык помочь мне избежать необходимости использовать ConfigureAwait (false) в моей библиотеке?

Разработчики библиотек иногда выражают недовольство необходимостью использования ConfigureAwait(false) и просят о менее агрессивных альтернативах.

В настоящее время их нет, по крайней мере, они не встроены в язык / компилятор / среду выполнения. Однако существует множество предложений о том, как может выглядеть такое решение, например,

https://github.com/dotnet/csharplang/issues/645,

https://github.com/dotnet/csharplang/issues/2542,

https://github.com/dotnet/csharplang/issues/2649,

https://github.com/dotnet/csharplang/issues/2746.

Если это важно для вас, и вы чувствуете, что у вас есть новые и интересные идеи, можете поделиться своими мыслями.

 

Источник



Exception: Object reference not set to an instance of an object.
Posted on 12. December 2019

Знакомство с System.Threading.Channels

Проблемы «производитель / потребитель» существуют везде, во всех аспектах нашей жизни. Последовательность приготовления заказа в заведениях быстрого питания: повар, нарезающий помидоры, которые передаются другому который складывает гамбургер, который предают работнику выдачи вашего заказа, который вы после с удовольствием съедаете. Почтовые водители доставляют почту по всем своим маршрутам, вы либо наблюдаете за прибывшим грузовиком и забираете свои посылки, либо же проверяете ящик придя с работы. Сотрудник авиакомпании выгружает чемоданы из грузового отсека реактивного лайнера, помещая их на конвейерную ленту, где они доставляются другому работнику, который переносит сумки в фургон и доставляет их на еще один конвейер, который привезет их к вам. Счастливая пара готовится разослать приглашения на свою свадьбу, причем один партнер закрывает конверты, передает другому который заклеивает и кладет в ящик.

Как разработчики программного обеспечения, регулярно наблюдаем, как события из нашей повседневной жизни проникают в наше программное обеспечение, и проблемы «производитель/потребитель» не являются исключением. Любой, кто собирал команды в командной строке, использовал производителя/потребителя, причем стандартный вывод одной программы передается как стандартный ввод другой. Любой, кто запустил несколько загрузок данных с нескольких сайтов или вычисления дискретных задач использовал метод производитель/потребитель, с потребителем агрегируя результаты для отображения или дальнейшей обработки.  Кто пытался распараллелить конвейер, явно использовал этот метод. И так далее.

У всех этих сценариев, происходящих в реальной жизни или в жизни программного обеспечения, есть что-то общее: есть какой-то механизм для передачи результатов от производителя к потребителю. Сотрудник фаст-фуда кладет гамбургеры на полку, из которой возьмет их другой работник, для выдачи заказа клиенту. Работник почты кладет посылки в почтовый ящик. Руки помолвленной пары встречаются, чтобы передать материалы от одного к другому. В программном обеспечении такая передача требует некоторой структуры данных для облегчения транзакции, хранилища, которое может использовать производитель для передачи результата и, возможно, буферизовать больше, в то же время позволяя потребителю получать уведомление о наличии одного или нескольких результатов. Вступление в System.Threading.Channels.

Что такое Канал?

Мне часто проще понять некоторые технологии, реализовав для себя простую версию. При этом я узнаю о различных проблемах, которые разработчики этой технологии, возможно должны были устранить, и о наилучшем способе использования функционала.  Для этого давайте начнем знакомство с System.Threading.Channels, реализовав «канал» с нуля.

Канал - это просто структура данных, используемая для хранения полученных данных для извлечения потребителем, и соответствующая синхронизация, позволяющая это безопасно выполнять, одновременно с включением соответствующих уведомлений в обоих направлениях. Существует множество возможных проектных решений. Должен ли канал содержать неограниченное количество элементов? Что должно произойти, когда он заполняется? Насколько критична производительность? Нужно ли пытаться минимизировать синхронизацию?  Можем ли сделать какие-либо предположения о том, сколько производителей и потребителей может быть допущено одновременно? В целях быстрого написания простого канала, давайте сделаем упрощающие предположения, что нам не нужно применять какие-либо конкретные ограничения и что нам не нужно слишком беспокоиться о дополнительных расходах. Разработчики также составили простой API.

Для начала нам нужен наш тип, к которому добавим несколько простых методов:

public sealed class Channel<T>

{

    public void Write(T value);

    public ValueTask<T> ReadAsync(CancellationToken cancellationToken = default);

}

 

Метод Write позволяет нам его использовать для вывода данных в канал, и ReadAsync метод дает нам потреблять от него. Так как решили, что наш канал неограничен, ввод данных в него всегда завершается успешно и синхронно, так же, как запрос Add в List<T> поэтому сделали его не асинхронным и возвращающим пустоту. В противоположность, наш метод использования это ReadAsync который является асинхронным, потому что данные, которые хотим использовать, могут быть еще не доступны, и, таким образом, нам нужно будет дождаться их обновлений.  И пока начинаем разработку, не слишком обеспокоены производительностью, также не хотим иметь много ненужных дополнительных расходов. Так как ожидаем, что будем читать, данные которые уже доступны для использования, метод ­­­­­ ReadAsync возвращает ValueTask<T> а не к Task<T>, так что можем сделать это без выделения при синхронном завершении.

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

private readonly ConcurrentQueue<T> _queue = new ConcurrentQueue<T>();
private readonly SemaphoreSlim _semaphore = new SemaphoreSlim(0);

Используем ConcurrentQueue<T> для хранения данных, освобождая нас от необходимости делать собственную блокировку для защиты структуры данных буферизации, такую как ConcurrentQueue<T> она является потоко-безопасной для любого количества производителей/потребителей. И используем SempahoreSlim он помогает координировать между производителями и потребителей и уведомлять потребителей о поступлении дополнительных данных.

Наш метод Write прост. Ему нужно сохранить данные в очереди и увеличить счетчик SemaphoreSlim, “публикуя” его:

public void Write(T value)
{
    _queue.Enqueue(value); // store the data
    _semaphore.Release(); // notify any consumers that more data is available
}

 

Метод ReadAsync почти так же прост. Нужно подождать, пока данные будут доступны, а затем вынуть их.

public async ValueTask<T> ReadAsync(CancellationToken cancellationToken = default)
{
    await _semaphore.WaitAsync(cancellationToken).ConfigureAwait(false); // wait
    bool gotOne = _queue.TryDequeue(out T item); // retrieve the data
    Debug.Assert(gotOne);
    return item;
}

 

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

На этом то все: у нас есть основной канал. Если все, что вам нужно, это базовые функции, такая реализация вполне разумна. Разумеется, требования часто более значимы как для производительности, так и для API, необходимых для обеспечения большего количества сценариев.

Теперь, когда понимаем основы того, что предоставляет канал, можем перейти к рассмотрению реальных API-интерфейсов System.Threading.Channel.

 

Представляем System.Threading.Channels

Основные абстракции, представленные в библиотеке System.Threading.Channels, написаны так:

public abstract class ChannelWriter<T>
{
    public abstract bool TryWrite(T item);
    public virtual ValueTask WriteAsync(T item, CancellationToken cancellationToken = default);
    public abstract ValueTask<bool> WaitToWriteAsync(CancellationToken cancellationToken = default);
    public void Complete(Exception error);
    public virtual bool TryComplete(Exception error);
}

 

и читается:

public abstract class ChannelReader<T>
{
    public abstract bool TryRead(out T item);
    public virtual ValueTask<T> ReadAsync(CancellationToken cancellationToken = default)
    public abstract ValueTask<bool> WaitToReadAsync(CancellationToken cancellationToken = default);
    public virtual IAsyncEnumerable<T> ReadAllAsync([EnumeratorCancellation] CancellationToken cancellationToken = default);
    public virtual Task Completion { get; }
}

 

Только что завершил свою собственную разработку и внедрение простого канала, большая часть поверхности API должна быть знакома. ChannelWriter<T> обеспечивает метод TryWrite, который очень похож на наш метод записи; тем не менее, это абстрактно и метод проб, который возвращает Boolean учитывать тот факт, что некоторые реализации могут быть ограничены в количестве элементов они могут на нем храниться и если канал был заполнен так, что запись не могла завершиться синхронно, TryWrite потребуется вернуть false, чтобы указать, что запись была неудачной.  Тем не менее ChannelWriter<T> также обеспечивает метод WriteAsync; в таком случае, канал переполнен и запись должна ждать (часто упоминается как «обратное воздействие»), можно использовать WriteAsync, с производителем в ожидании результата WriteAsync его можно будет использовать, только когда пространство освободиться.

Конечно, бывают ситуации, когда код может не сразу создать значение; если полученные значения будут дорогим или если значение, представляет собой дорогой ресурс, (к примеру, это большой объект, который занял бы много памяти, или, может быть, он хранит кучу открытых файлов) в таких случаях, производитель работает быстрее, чем потребитель, производитель может захотеть отложить создание значения, пока не убедиться, что запись будет успешной. Для этого, есть соответствующий сценарий WaitToWriteAsync. Создатель может ожидать WaitToWriteAsync возвращение true, и только затем создатель выбирает значение TryWrite или WriteAsync на канал.

Обратите внимание что, WriteAsync виртуальный. Некоторые ее осуществления могут выбрать более оптимизированные переходы, но с абстрактным TryWrite и WaitToWriteAsync, базовый тип может обеспечить благоразумную реализацию, что немного сложнее, чем эта:

public async ValueTask WriteAsync(T item, CancellationToken cancellationToken)
{
    while (await WaitToWriteAsync(cancellationToken).ConfigureAwait(false))
        if (TryWrite(item))
            return;
 
    throw new ChannelCompletedException();
}

 

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

В этом примере также показано, почему WaitToWriteAsync возвращает ValueTask<bool> вместо ValueTask, а также ситуации за пределами полного буфера, в которых TryWrite может возвращать false. Каналы поддерживают концепцию завершения, когда производитель может сигнализировать потребителю, что больше не будет произведено никаких товаров, что позволяет потребителю прекратить попытки потреблять. Это делается с помощью методов Complete или TryComplete , ранее показанных на ChannelWriter<T> (Complete  реализован для вызова TryComplete  и throw, если он возвращает false). Но если один продюсер помечает канал как завершенный, другим продюсерам нужно знать, что они больше не могут писать в канал; в этом случае TryWrite возвращает false, WaitToWriteAsync также возвращает false, а WriteAsync генерирует исключение ChannelCompletedException.

Большинство членов ChannelReader<T>, вероятно, тоже говорят сами за себя.TryRead  попытается синхронно извлечь следующий элемент из канала. ReadAsync также извлекает следующий элемент из канала, но если элемент не может быть получен синхронно, он возвращает задачу. И WaitToReadAsync возвращает ValueTask<bool>, который служит уведомлением о доступе элемента. Как и в случае WriteAsync для ChannelWriter<T>, ReadAsync является виртуальным, с базовой реализацией, осуществляемой в терминах абстрактных TryRead  и WaitToReadAsync; это не точная реализация в базовом классе, но очень близка:

public async ValueTask<T> ReadAsync(CancellationToken cancellationToken)
{
    while (true)
    {
        if (!await WaitToReadAsync(cancellationToken).ConfigureAwait(false))
            throw new ChannelClosedException();
 
        if (TryRead(out T item))
            return item;
    }
}

 

Существует множество типичных шаблонов того, как использовать канал ChannelReader<T>. Если он представляет собой бесконечный поток значений, один из подходов состоит в том, чтобы просто сидеть в бесконечном цикле потребителя через ReadAsync:

while (true)
{
    T item = await channelReader.ReadAsync();
    Use(item);
}

 

Конечно, если поток значений не является бесконечным и канал будет в какой-то момент помечен как завершенный, после того как потребители очистят канал от всех своих данных, последующие попытки чтения из него будут отброшены. Напротив, TryRead  вернет false, как и WaitToReadAsync. Итак, более распространенная модель потребления - через вложенный цикл:

while (await channelReader.WaitToReadAsync())
    while (channelReader.TryRead(out T item))
        Use(item);

 

Вместо этого внутреннее «while» могло бы быть простым «if», но наличие тесного внутреннего цикла позволяет экономному разработчику избегать небольших дополнительных издержек WaitToReadAsync, так что TryRead будет успешно использовать этот элемент. Фактически, это точный шаблон, используемый методом ReadAllAsync. ReadAllAsync был представлен в .NET Core 3.0 и возвращает IAsyncEnumerable<T>. Это позволяет всем данным быть прочитанными из канала, используя знакомые языковые конструкции:

await foreach (T item in channelReader.ReadAllAsync())
    Use(item);

 

А базовая реализация виртуального метода использует точный шаблон вложенного цикла, показанный ранее с WaitToReadAsync и TryRead:

public virtual async IAsyncEnumerable<T> ReadAllAsync(
    [EnumeratorCancellation] CancellationToken cancellationToken = default)
{
    while (await WaitToReadAsync(cancellationToken).ConfigureAwait(false))
        while (TryRead(out T item))
            yield return item;
}

 

Последняя часть ChannelReader<T> это Completion. Возвращает Task, который будет выполнено после завершения чтения канала. Это означает, что писатель отметил, что канал завершен, и все данные были использованы.

Реализация встроенных каналов

Итак, мы знаем, как писать писателям и читать письма от читателей ... но откуда мы берем этих писателей и читателей? 

Тип Channel<TWrite, TRead> предоставляет свойство Writer и свойство Reader, которое возвращает ChannelWriter<TWrite> и ChannelReader<TRead>  соответственно:

public abstract class Channel<TWrite, TRead>
{
    public ChannelReader<TRead> Reader { get;  }
    public ChannelWriter<TWrite> Writer { get; }
}

 

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

public abstract class Channel<T> : Channel<T, T> { }

 

Нетипичный Channel type обеспечивает фабрики для нескольких реализаций Channel