C# (C Sharp) programming

🖥 Многопоточное vs асинхронное программирование

▶️Вообще, есть несколько разных понятий:
• Конкурентное исполнение
• Параллельное исполнение
• Многопоточное исполнение
• Асинхронное исполнение
Каждый из этих терминов строго определен и имеет четкое значение.

🟡Конкурентность
Конкурентность — это наиболее общий термин, который говорит, что одновременно выполняется более одной задачи.

🟡Параллельное исполнение
Параллельное исполнение подразумевает наличие более 1 вычислительного устройства (например, процессора), которые будут одновременно выполнять несколько задач.
Параллельное исполнение — это строгое подмножество конкурентного исполнения. Это значит, что на компьютере с 1 процессором параллельное программирование - невозможно

🟡Многопоточность
Многопоточность — это один из способов реализации конкурентного исполнения путем выделения абстракции "рабочего потока" (worker thread).
Потоки "абстрагируют" от пользователя низкоуровневые детали и позволяют выполнять более чем одну работу "параллельно". Операционная система, среда исполнения или библиотека прячет подробности того, будет многопоточное исполнение конкурентным (когда потоков больше чем физических процессоров), или реально параллельным.

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


▶️Ну или более неформально: скажем, вам нужно выкопать во дворе бассейн.

• Вы взяли лопату и копаете. Это однопоточная работа

• Вы пригласили друга Васю и копаете вместе, периодически задевая друг-друга лопатами. Это многопоточная работа

• Пока вы копаете бассейн, Вася копает канаву под водопровод. Никто никому не мешает. Это распараллеливание

• Вы пригласили бригаду землекопов, а сами с Васей пошли отдыхать. Когда бригада все сделает, к вам придут за деньгами. Это асинхронная работа.
Количество лопат в хозяйстве - это количество ядер в системе

📎 Подробнее

@csharp_ci

🖥 Ссылочные локальные переменные в C#

🟡Начиная с версии C# 7 в языке появилась возможность, позволяющая объявить локальную переменную, ссылающуюся на элемент массива или на поле в объекте:

int[] simpleArray = {0, 1, 2, 3, 4, 5, 6, 7, 8};
ref int simpleElementRef = ref simpleArray[3];

В этом примере simpleElementRef — ссылка на simpleArray[3]. Изменение simpleElementRef приводит к изменению элемента массива:

simpleElementRef *= 15;
Console.WriteLine(simpleElementRef);      // 15
Console.WriteLine(simpleArray[3]);        // 15

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

🟡Также ссылочные локальные переменные можно возвращать из методов. В результате получаем возвращаемое ссылочное значение:

static string X = "Старое значение";
static ref string GetX() => ref X; // Возвращает ссылочное значение

static void Main()
{
   ref string xRef = ref GetX(); // Присваивает результат ссылочной локальной переменной
            
   xRef = "Новое значение";
            
   Console.WriteLine(X); // Выводит Новое значение
}

📎 Подробнее

@csharp_ci

🖥 Факт дня — Task.Yield()

Повторение — мать учения и основа научного метода, так что приступим)
Task.Yield() возвращает специальное значение, предназначенное для передачи оператору await, и в отрыве от этого оператора не имеющее смысла.

Конструкция же await Task.Yield() делает довольно простую вещь — прерывает текущий метод и сразу же планирует его продолжение в текущем контексте синхронизации.

Используется же эта конструкция для разных целей.

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

protected override async void OnClosing(CancelEventArgs e)
{
    e.Cancel = true;
    await Task.Yield(); 
    // (какая-то логика)
}

🟡Во-вторых, эта конструкция используется для очистки синхронного контекста вызова. Например, так можно "закрыть" текущую транзакцию (ambient transaction):

using (var ts = new TransactionScope()) {
  // ...
  Foo();
  // ...
  ts.Complete();
}

async void Foo() {
  // ... тут мы находимся в контексте транзакции
  if (Transaction.Current != null) await Task.Yield();
  // ... а тут его уже нет!
}

🟡В-третьих, эта конструкция может очистить стек вызовов. Это может быть полезным, если программа падает с переполнением стека при обработке кучи вложенных продолжений.

Например, рассмотрим упрощенную реализацию AsyncLock:

class AsyncLock
{
    private Task unlockedTask = Task.CompletedTask;

    public async Task<Action> Lock()
    {
        var tcs = new TaskCompletionSource<object>();

        await Interlocked.Exchange(ref unlockedTask, tcs.Task);

        return () => tcs.SetResult(null);
    }
}

Здесь поступающие запросы на получение блокировки выстраиваются в неявную очередь на продолжениях. Казалось бы, что может пойти не так?

private static async Task Foo()
{
    var _lock = new AsyncLock();
    var unlock = await _lock.Lock();

    for (var i = 0; i < 100000; i++) Bar(_lock);

    unlock();
}

private static async void Bar(AsyncLock _lock)
{
    var unlock = await _lock.Lock();
    // do something sync
    unlock();
}

Здесь продолжение метода Bar вызывается в тот момент, когда другой метод Bar выполняет вызов unlock(). Получается косвенная рекурсия между методом Bar и делегатом unlock, которая быстро сжирает стек и ведет к его переполнению.

Добавление же вызова Task.Yield() перенесет исполнение в "чистый" фрейм стека, и ошибка исчезнет:

class AsyncLock
{
    private Task unlockedTask = Task.CompletedTask;

    public async Task<Action> Lock()
    {
        var tcs = new TaskCompletionSource<object>();

        var prevTask = Interlocked.Exchange(ref unlockedTask, tcs.Task);

        if (!prevTask.IsCompleted) 
        {
          await prevTask;
          await Task.Yield();
        }

        return () => tcs.SetResult(null);
    }
}

@csharp_ci

#ПятничныйКвиз #карательныйсишарп

🖥 Как запустить C# юнит-тесты на Linux в GitHub Actions?

В этой статье мы разберёмся с запуском C#-тестов на Linux и последующую публикацию их в открытом репозитории кода на GitHub.

План:
├╼ Устанавливаем .NET на Ubuntu 22.04
├╼ Создаём проект
├╼ Запускаем сборку в GitHub Actions
├╼ Используем секреты в коде тестов
╰╼ Размещаем секреты в GitHub Actions Secrets

📎 Туториал
🖥 GitHub

@csharp_ci

🖥 Как можно реализовать ограничение на одновременное скачивание файлов?

▶️Итак, есть сервис, который отдает пользователям видео файлы, реализован метод для скачивания файла, который отдает файл через метод File:

[HttpGet("file/{guid}/download")]
        [ProducesResponseType(StatusCodes.Status200OK)]
        public async Task<IActionResult> DownloadFile([FromRoute] Guid guid)
        {
            var file = await _mediaContentService.DownloadFile(guid);

            return File(file.Stream, file.ContentType, file.FileName);
        }

Можно ли каким-либо образом реализовать ограничение на скачивание файла, чтобы, например, в единицу времени не больше N пользователей качало файл?


▶️Проблема с методом File — он возвращает ленивый ответ. Т.е. он не читает весь поток сразу, а ждет пока будет вызван метод от IActionResult.
Чтобы эту проблему решить, надо знать, когда файл точно отправлен.
Можно сделать специальный декоратор. Например:

[ApiController]
[Route("[controller]")]
public class SampleController : ControllerBase
{
    private readonly IRateLimiter _rateLimiter;

    public SampleController(IRateLimiter rateLimiter)
    {
        _rateLimiter = rateLimiter;
    }

    [HttpGet("connection")]
    public async Task<IActionResult> DownLoadFile(Guid file)
    {
        var stream = await GetFileStream(file);
        return new RateLimiterFileActionResult(File(stream, "content/type", "sample.txt"), _rateLimiter);
    }
}

class RateLimiterFileActionResult : IActionResult
{
    private readonly IActionResult _actionResultImplementation;
    private readonly IRateLimiter _rateLimiter;

    public RateLimiterFileActionResult(IActionResult actionResultImplementation, IRateLimiter rateLimiter)
    {
        _actionResultImplementation = actionResultImplementation;
        _rateLimiter = rateLimiter;
    }

    public async Task ExecuteResultAsync(ActionContext context)
    {
        try
        {
            await _rateLimiter.ObtainAsync(context.HttpContext.RequestAborted);
            await _actionResultImplementation.ExecuteResultAsync(context);
        }
        finally
        {
            await _rateLimiter.ReleaseAsync(context.HttpContext.RequestAborted);
        }
    }
}

public interface IRateLimiter
{
    public Task ObtainAsync(CancellationToken token);
    public Task ReleaseAsync(CancellationToken token);
}

Стоит заметить, что блокировка берётся внутри метода декоратора, а не в методе контроллера.

@csharp_ci

🖥 Чем out отличается от ref?

▶️Функция с параметром с ключевым словом out даёт такой же результат, как и с ref.

Такой код:

private void func(out string value)
{
    value = "Hello World!";
}

Даёт такой же эффект, как и:

private void func(ref string value)
{
    value = "Hello World!";
}

В чём же разница между out и ref?


▶️Разница в том, что out — это выходной параметр, а ref — входно-выходной.

Для ref-параметра вы должны передать его инициализированным, и можете пользоваться его исходным значением. А для out-параметра вы не обязаны инициализировать его перед вызовом функции, не можете использовать его значение в функции до присваивания, и обязаны инициализировать его в функции.

(Таким образом, ref-параметр немного напоминает инициализированную локальную переменную, а out-параметр — неинициализированную.)

Иллюстрация:

private void func1(out string value)
{
    Console.WriteLine(value); // нельзя, value не инициализировано
    if (false)
        return;               // нельзя, забыли установить значение value
    value = "Hello World!";
}

string s1;
func1(out s1);
private void func2(ref string value)
{
    Console.WriteLine(value); // можно
    if (false)
        return;               // не проблема, у value остаётся старое значение
    value = "Hello World!";
}

string s2;
func2(ref s2); // нельзя, функция имеет право использовать значение,
               // значит, оно должно быть инициализировано сначала

Таким образом, out-параметр — это как бы дополнительное возвращаемое значение функции. А ref-параметр — просто параметр, изменения которого видны снаружи функции.

@csharp_ci

🖥 Пишем на C# программу для поиска файлов, используя ProgressBar и BackgroundWorker

Если вы хотите глубже разобраться, как работать с элементами ProgressBar и BackgroundWorker в C#, с элементом FolderBrowserDialog, а также с событиями DoWork, ProgressChanged, RunWorkerCompleted, то большая часть этой статьи может принести вам много нового опыта.
Уверен, будет полезно)

Будущее приложение по поиску файлов будет выглядеть как на изображении
📎 Пошаговая реализация программы

@csharp_ci

🖥 Что лучше, возвращать null, или пустую коллекцию?

▶️Если возвращаемый тип — коллекция, что лучше: возвращать null или пустую коллекцию? Есть ли общепринятая практика?


▶️Вопрос здесь в семантике.
На запрос «дайте мне список всех пользователей» пустая коллекция имеет очевидный смысл: «окей, вот вам список всех пользователей, их ровно 0 штук».

С другой стороны, возвращённый null может означать что угодно: «я не знаю, сколько пользователей», «количество пользователей ещё не подсчитано», «текущая база данных вообще не имеет понятия пользователь», что угодно.
То есть смысл пустой коллекции всегда ясен, смысл null не определён.

▶️Ещё одна причина возвращать пустые коллекции, а не null — так вы избавите пользователя от необходимости писать утомительный код проверок на null и, соответственно, избавите его от большого количества NullReferenceException, если он таковой код написать забыл. Хорошим примером могут быть случаи, когда коллекции задействованы в цепочках методов вида

var res = FirstMethod().SecondMethod().ThirdMethod();

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

Кстати, в LINQ именно так и делается. Например, следующий код вполне нормально работает без выбрасывания исключений, хотя очевидно, что ни один из элементов коллекции не удовлетворяет условию лямбды в Where:

var res2 = new[] { 1, 2, 3 }.Where(x => x > 10).Select(x => x);

@csharp_ci

#ПятничныйКвиз

@csharp_ci

🖥 Путь C# Web программиста

Держите очень полезную roadmap от Михаила Флёнова, автора «Библия C#»
Это подборка видео и статей, которые помогут на пути C# Web разработчика
Пользуйтесь)

📎 Roadmap

@csharp_ci

🖥 Event и delegate: в чем отличие?

Начнём с того, что event и delegate — это 2 абсолютно разных вещи. Разница между полем-делегатом и event'ом примерно такая же, как между полем и свойством: event иногда выглядит как делегатное поле. Давайте разберёмся в этом.

⏩delegate — это класс, содержащий в себе «шаблон» метода, то есть, сигнатуру метода. Переменная делегатного типа — объект типа MulticastDelegate (точнее, производного от него), который может содержать один или несколько объектов, представляющих собой методы с совместимой с «шаблоном» сигнатурой (контр- и ковариантность немного усложняет картину). То есть это как бы переменная, которая может содержать функции. Для таких переменных определена операция +, которая комбинирует слагаемые-функции в одну новую функцию, и симметричная операция -. Эти операции автоматически порождают производные операции += и -=.

⏩event же — это просто пара методов в классе, обозначаемых как add и remove, и имеющих произвольную семантику, выбранную программистом. (Аналог — геттер и сеттер свойства.) В имплементации по умолчанию для event'а заводится скрытое поле делегатного типа, а add/remove добавляют или убирают из него методы (под lock'ом). (Чтобы немного запутать картину, это скрытое поле доступно по тому же имени, что и event.) Функции add/remove, составляющие event, *вызываются* соответственно как += и -=. Никаких операций +/-, разумеется, нету.

📎 Подробнее

@csharp_ci

🖥 Море полезных ресурсов по C#

Здесь и сборники рецептов, и теория по сетевому программированию, и паттерны проектирования приложений, и описание принципов работы асинхронного кода
Даже ссылки на обзоры IDE и инструменты для работы с C#
Рекомендую)

📎 Ссылка

@csharp_ci