Язык программирования C#9 и платформа .NET5 - Эндрю Троелсен

class="p1">• Лямбда-выражения являются всего лишь замаскированными анонимными методами (и значительно улучшают читабельность).

• Анонимные методы представляют собой сокращенные обозначения для размещения экземпляра низкоуровневого делегата и ручного построения целевого метода делегата.

Хотя здесь мы погрузились в детали чуть глубже, чем возможно хотелось, приведенное обсуждение должно было способствовать пониманию того, что фактически делают "за кулисами" дружественные к пользователю операции запросов С#.

Резюме

LINQ — это набор взаимосвязанных технологий, которые были разработаны для предоставления единого и симметричного стиля взаимодействия с данными несходных форм. Как объяснялось в главе, LINQ может взаимодействовать с любым типом, реализующим интерфейс IEnumerable<T>, в том числе с простыми массивами, а также с обобщенными и необобщенными коллекциями данных.

Было показано, что работа с технологиями LINQ обеспечивается несколькими средствами языка С#. Например, учитывая тот факт, что выражения запросов LINQ могут возвращать любое количество результирующих наборов, для представления лежащего в основе типа данных принято использовать ключевое слово var. Кроме того, для построения функциональных и компактных запросов LINQ могут применяться лямбда-выражения, синтаксис инициализации объектов и анонимные типы.

Более важно то, что операции запросов LINQ в C# на самом деле являются просто сокращенными обозначениями для обращения к статическим членам типа System.Linq.Enumerable. Вы узнали, что большинство членов класса Enumerable оперируют с типами делегатов Func<T> и для выполнения запроса могут принимать на входе адреса существующих методов, анонимные методы или лямбда-выражения.

Глава 14

Процессы, домены приложении и контексты загрузки

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

Выражаясь кратко, домены приложений (Application Domain или просто AppDomain) представляют собой логические подразделы внутри заданного процесса, обслуживающего набор связанных сборок .NET Core. Как вы увидите, каждый домен приложения в дальнейшем подразделяется на контекстные границы, которые используются для группирования вместе похожих по смыслу объектов .NET Core. Благодаря понятию контекста исполняющая среда способна обеспечивать надлежащую обработку объектов со специальными требованиями.

Хотя вполне справедливо утверждать, что многие повседневные задачи программирования не предусматривают работу с процессами, доменами приложений или контекстами загрузки напрямую, их понимание важно при взаимодействии с многочисленными API-интерфейсами .NET Core, включая многопоточную и параллельную обработку, а также сериализацию объектов.

Роль процесса Windows

Концепция "процесса" существовала в операционных системах Windows задолго до выпуска платформы .NET/.NET Core. Пользуясь простыми терминами, процесс — это выполняющаяся программа. Тем не менее, формально процесс является концепцией уровня операционной системы, которая применяется для описания набора ресурсов (таких как внешние библиотеки кода и главный поток) и необходимых распределений памяти, используемой функционирующим приложением. Для каждого загруженного в память приложения .NET Core операционная система создает отдельный изолированный процесс для применения на протяжении всего времени его существования.

При использовании такого подхода к изоляции приложений в результате получается намного более надежная и устойчивая исполняющая среда, поскольку отказ одного процесса не влияет на работу других процессов. Более того, данные в одном процессе не доступны напрямую другим процессам, если только не применяются специфичные инструменты вроде пространства имен System.IO.Pipes или класса MemoryMappedFile.

Каждый процесс Windows получает уникальный идентификатор процесса (process identifier — PID) и может по мере необходимости независимо загружаться и выгружаться операционной системой (а также программно). Как вам возможно известно, в окне диспетчера задач Windows (открываемом по нажатию комбинации клавиш <Ctrl+Shift+Esc>) имеется вкладка Processes (Процессы), на которой можно просматривать разнообразные статические данные о процессах, функционирующих на машине. На вкладке Details (Подробности) можно видеть назначенный идентификатор PID и имя образа (рис. 14.1).

Роль потоков

Каждый процесс Windows содержит начальный "поток", который действует как точка входа для приложения. Особенности построения многопоточных приложений на платформе .NET Core рассматриваются в главе 15; однако для понимания материала настоящей главы необходимо ознакомиться с несколькими рабочими определениями. Поток представляет собой путь выполнения внутри процесса. Выражаясь формально, первый поток, созданный точкой входа процесса, называется главным потоком. В любой программе .NET Core (консольном приложении, Windows-службе, приложении WPF и т.д.) точка входа помечается с помощью метода Main() или файла, содержащего операторы верхнего уровня. При обращении к этому коду автоматически создается главный поток.

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

Учитывая такой потенциальный недостаток однопоточных приложений, операционные системы, которые поддерживаются .NET Core, и сама платформа .NET Core предоставляют главному потоку возможность порождения дополнительных вторичных потоков (называемых рабочими потоками) с использованием нескольких функций из API-интерфейса Windows, таких как CreateThread(). Каждый поток (первичный или вторичный) становится уникальным путем выполнения в процессе и имеет параллельный доступ ко всем совместно используемым элементам данных внутри этого процесса.

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

На некоторых машинах многопоточность по большей части является иллюзией, обеспечиваемой операционной системой. Машины с единственным (не поддерживающим гиперпотоки) центральным процессором не обладают возможностью обработки множества потоков в одно и то же время. Взамен один центральный процессор выполняет по одному потоку за единицу времени (называемую квантом времени), частично основываясь на приоритете потока. По истечении выделенного кванта времени выполнение существующего потока приостанавливается, позволяя выполнять работу другому потоку. Чтобы поток не "забывал", что происходило до того, как его выполнение было приостановлено, ему предоставляется возможность записывать данные в локальное хранилище потоков (Thread Local Storage — TLS) и выделяется отдельный стек вызовов