Аннотация: Когда была выпущена первая версия .NET Framework в обогащенных клиентских приложениях существовал шаблон, ориентированный на циклы обработки сообщений, где использовалась встроенная очередь для передачи единиц исполнения из рабочих потоков. Далее было разработано обобщенное решение ISynchronizeInvoke, в рамках которого поток-источник может поставить делегат в очередь к потоку-приемнику и, как необязательный вариант, ожидать завершения этого делегата. После введения поддержки асинхронных страниц в архитектуру ASP.NET шаблон ISynchronizeInvoke не походил, так как асинхронные ASP.NET-страницы не сопоставлены с единственным потоком. Это стало причиной создания ещё более обобщенного решения – SynchronizationContext, что и является предметом исследования. В статье на практических примерах представлено, как следует обновлять элементы пользовательского интерфейса из рабочих потоков, не нарушая потокобезопасность пользовательского приложения. В этом аспекте предлагаются решения: с применением методов Beginlnvoke или Invoke для постановки этого делегата в очередь сообщений потока пользовательского интерфейса; с захватом контекста синхронизации потока пользовательского интерфейса посредством свойства Current класса SynchronizationContext; с применением устаревшего класса BackgroundWorker, обеспечивающий неявный захват контекста синхронизации потока пользовательского интерфейса. Не оставлена без внимания особенность реализации абстрактного класса SynchronizationContext в платформе ASP.NET. Сформированы практические рекомендации по использованию механизма маршализации на примере разработки мультиклиентного чата с централизованным сервером.

Ключевые слова: параллельное программирование, NET Framework, делегаты, контекст синхронизации, Universal Windows Platform, Windows Presentation Foundation, Windows Forms, многопоточность, программирование, шаблоны проектирования

Abstract: When the first version of the .NET Framework was released, there was a pattern in enriched client applications that focused on message processing loops, where an embedded queue was used to pass execution units from worker threads. A generalized ISynchronizeInvoke solution was then developed in which the source thread could queue a delegate to the destination thread and, as an optional option, wait for that delegate to complete. After asynchronous page support was introduced into the ASP.NET architecture, the ISynchronizeInvoke pattern did not work because asynchronous ASP.NET pages are not mapped to a single thread. This was the reason for creating an even more generalized solution – SynchronizationContext, which is the subject of the research. The article uses practical examples to show how to update UI elements from worker threads without breaking thread-safety of the user application. Solutions proposed in this aspect are: using Beginlnvoke or Invoke methods to put this delegate into the UI thread message queue; capturing the UI thread synchronization context via the Current property of the SynchronizationContext class; using the deprecated BackgroundWorker class, which provides an implicit capture of the UI thread synchronization context. The peculiarity of implementation of the SynchronizationContext abstract class in ASP.NET platform is not left unnoticed. Practical recommendations on the use of marshalling mechanism on the example of development of multiclient chat with a centralized server are formulated.

Keywords: parallel programming, NET Framework, delegates, Universal Windows Platform, synchronization context, Windows Presentation Foundation, Windows Forms, multithreading, programming, design patterns

Аннотация: The subject of the study is the architecture of the RSS feed aggregation system. The author considers in detail such aspects of the topic as choosing the right data aggregation strategy, an approach to scaling a distributed system, designing and implementing the main modules of the system, such as an aggregation strategy definition module, a content aggregation module, a data processing module, a search module. Particular attention in this study is given to a detailed description of the libraries and frameworks chosen for the implementation of the system under consideration, as well as databases. The main part of the system under consideration is implemented in the C# programming language (.Net Core) and is cross-platform. The study describes the interaction with the main data stores used in the development of the aggregation system, which are PostgreSQL and Elasticsearch. The main conclusion of the study is that before developing an aggregation system, it is necessary to analyze the publication activity of data sources, on the basis of which it is possible to form an acceptable strategy for updating the search index, saving a significant amount of resources. computing power. Content aggregation systems, such as the one considered in this study, should be distributed, built on the basis of event-driven and microservice architectures. This approach will make the system resistant to high loads and failures, as well as easily expandable. The author's special contribution to the study of the topic is a detailed description of the high-level architecture of the RSS aggregator, designed to process 50,000 channels.

Ключевые слова: content categorization, cross-platform, fault tolerance, scalability, competing consumers pattern, microservice architecture, RabbitMQ, Elasticsearch, RSS aggregation, expert system