SoftLab.NET 2014

21.12.2014 по koissakh kadderah

20 Декабря была веб-конференция SoftLab.NET 2014 компании Luxoft на которой я рассказывал про Threading Pattern Library из комплекта поставки PostSharp. Эта библиотека шаблонов действительно упрощает работу с многопоточностью. В следующем году я хочу подробно про это написать, так как там много нюансов обнаруживается, но сейчас краткий обзор доступен в презентации.

Hard’n’Heavy!

Конвейер (Pipeline) — IV

13.12.201205.12.2012 по koissakh kadderah

Ближе к жизни

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

Итак, обычно на каждую фазу бывает по сервису. В таком случае, все же будет разумно, чтобы сервис имел поток публикуемых результатов.

public class ReadData {
    private readonly ReplaySubject&lt;string&gt; stream = new ReplaySubject&lt;string&gt;();

    public IObservable&lt;string&gt; ReadStream {
        get { return stream; }
    } 

    public string Read(string s) {
        Task.Delay(TimeSpan.FromSeconds(1)).Wait();
        stream.OnNext(s);
        return s;
    }
}

public class ProcessData {
    private readonly ReplaySubject&lt;string&gt; stream = new ReplaySubject&lt;string&gt;();

    public IObservable&lt;string&gt; ProcessedStream {
        get { return stream; }
    } 

    public string Process(string s) {
        Task.Delay(TimeSpan.FromSeconds(2)).Wait();
        stream.OnNext(s);
        return s;
    }
}

public class WriteData {
    public void Write(string s) {
        Task.Delay(TimeSpan.FromSeconds(1)).Wait();
    }
}

public class ReadData {

private readonly ReplaySubject<string> stream = new ReplaySubject<string>();

public IObservable<string> ReadStream {

get { return stream; }

}

public string Read(string s) {

Task.Delay(TimeSpan.FromSeconds(1)).Wait();

stream.OnNext(s);

return s;

}

public class ProcessData {

private readonly ReplaySubject<string> stream = new ReplaySubject<string>();

public IObservable<string> ProcessedStream {

get { return stream; }

}

public string Process(string s) {

Task.Delay(TimeSpan.FromSeconds(2)).Wait();

stream.OnNext(s);

return s;

}

public class WriteData {

public void Write(string s) {

Task.Delay(TimeSpan.FromSeconds(1)).Wait();

}

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

Подробнее

Конвейер (Pipeline) — III

12.12.201205.12.2012 по koissakh kadderah

Конвейер для больших массивов

Редко кода требуется создать конвейер для небольшого количества данных. Даже не так. Конвейер по сути своей предназначен для неопределенного количества данных, когда неизвестно наперед сколько их будет, но что будет много – известно.

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

По сути код останется тем же, только надо увеличить количество элементов.

Линейную реализацию с перебором всех значений не будем рассматривать уже как совсем не интересную.

При работе с Task, замеры времени показывают среднее значение обработки в 51 секунду. Это означает, что все 60 потоков не создаются одновременно, а выстаиваются в какую-то очередь и все это безобразие занимает 51 секунду (разброс от 50 до 53 секунд), если использовать такой код:

foreach (var s in data) {
    var first = new Task&lt;string&gt;(() =&gt; service.StartPhase(s));
    var final = first.ContinueWith(t =&gt; service.MiddlePhase(t.Result))
                     .ContinueWith(t =&gt; service.FinalPhase(t.Result));
    tasks.Add(final);
    first.Start();
}

foreach (var s in data) {

var first = new Task<string>(() => service.StartPhase(s));

var final = first.ContinueWith(t => service.MiddlePhase(t.Result))

.ContinueWith(t => service.FinalPhase(t.Result));

tasks.Add(final);

first.Start();

}

Что совсем не оптимально и мы получаем огромное количество потоков. На скриншоте показана только часть потоков для первой фазы, ровно только же идет для второй и третьей. В общем ужас-ужас.

Подробнее

Конвейер (Pipeline) — II

11.12.201205.12.2012 по koissakh kadderah

Конвейер для небольших массивов

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

Обработка одного значения совсем не интересно, гораздо интереснее посмотреть временные затраты при небольших массивах. Для начала пусть будет 4 значения в массиве.

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

public class UpdateDataService {
    public string StartPhase(string s) {
        s += "s";
        Base(1);
        return s;
    }

    public string MiddlePhase(string s) {
        s += "m";
        Base(2);
        return s;
    }

    public string FinalPhase(string s) {
        s += "f";
        Base(1);
        return s;
    }

    private void Base(int seconds) {
        Task.Delay(TimeSpan.FromSeconds(seconds)).Wait();
    }
}

public class UpdateDataService {

public string StartPhase(string s) {

s += "s";

Base(1);

return s;

}

public string MiddlePhase(string s) {

s += "m";

Base(2);

return s;

}

public string FinalPhase(string s) {

s += "f";

Base(1);

return s;

}

private void Base(int seconds) {

Task.Delay(TimeSpan.FromSeconds(seconds)).Wait();

}

Ничего сложного, но зато можно отследить порядок выполнения фаз. При прохождении через сервис, мы должны получить значение с постфиксом «smf».

Подробнее

Конвейер (Pipeline) — I

10.12.201205.12.2012 по koissakh kadderah

Сложность 200-400

Практически всегда темы для статей происходят из жизни, из реальных проектов и проблем, которые надо решить. Иногда делаешь как проще и быстрее, а потом уже потихоньку перерабатываешь как надо. В этот раз, скорее всего, сразу получилось как надо =)

Преамбула

Задача в общем смысле стояла примерно так:

С некоторой периодичностью приходят файлы данных в xml;
Файлы надо распарсить;
Проверить данные, контрольные суммы, верность указания справочников;
Отправить пользователю на проверку суммарные данные;
Сохранить данные в базу.

Интуитивно понятно, что при обработки файлов применяется строгая последовательность шагов. Для каждого шага используется свой сервис и, для скорости, каждый шаг может выполнятся в отдельном потоке. Так я и сделал.

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

Подробнее

Async\Await методы и PostSharp

26.11.201225.11.2012 по koissakh kadderah

Сложность 300-400

Описание проблемы

Уже много чего написал насчет PostSharp, конкретных решений, кастом компонентов, общие принципы работы. Однако с выходом .Net 4.5 появилась новая фича со специальными словами async\await которые позволяют более просто и компактно описывать асинхронное поведение методов. Новый функционал хорош, но добавляет головной боли при использовании PostSharp, с методами помеченными async, использование классических аспектов не пройдет. Методы с маркером async разворачиваются в машину состояний, что не очень хорошо с точки зрения применения аспектов. Т.е. возьмем стандартную реализацию аспекта трассировщика с помощью PostSharp:

[Serializable]
public class TraceAttribute : OnMethodBoundaryAspect {
    public override void OnEntry(MethodExecutionArgs args) {
        var methodName = GetMethodName(args.Method);
        args.MethodExecutionTag = methodName;
        Console.WriteLine("Entering {0}", methodName);
        base.OnEntry(args);
    }

    public override void OnSuccess(MethodExecutionArgs args) {
        Console.WriteLine("{0} executed successfully", args.MethodExecutionTag);
        base.OnSuccess(args);
    }

    public override void OnException(MethodExecutionArgs args) {
        Console.WriteLine("{0} excepted : {1}", args.MethodExecutionTag, args.Exception);
        base.OnException(args);
    }

    private string GetMethodName(MethodBase method) {
        if (method.IsGenericMethod) {
            var genericArgs = method.GetGenericArguments();
            var typeNames = genericArgs.Select(t =&gt; t.Name);
            return string.Format("{0}&lt;{1}&gt;", method.Name, String.Join(",", typeNames));
        }

        return method.Name;
    }
}

[Serializable]

public class TraceAttribute : OnMethodBoundaryAspect {

public override void OnEntry(MethodExecutionArgs args) {

var methodName = GetMethodName(args.Method);

args.MethodExecutionTag = methodName;

Console.WriteLine("Entering {0}", methodName);

base.OnEntry(args);

}

public override void OnSuccess(MethodExecutionArgs args) {

Console.WriteLine("{0} executed successfully", args.MethodExecutionTag);

base.OnSuccess(args);

}

public override void OnException(MethodExecutionArgs args) {

Console.WriteLine("{0} excepted : {1}", args.MethodExecutionTag, args.Exception);

base.OnException(args);

}

private string GetMethodName(MethodBase method) {

if (method.IsGenericMethod) {

var genericArgs = method.GetGenericArguments();

var typeNames = genericArgs.Select(t => t.Name);

return string.Format("{0}<{1}>", method.Name, String.Join(",", typeNames));

}

return method.Name;

}

И применим его к тестовому примеру с вызовом синхронных и асинхронных методов с исключениями и без:

internal class Program {
    private static void Main(string[] args) {
        Start().Wait();

        Console.WriteLine("All done");
        Console.ReadKey();
    }

    private static async Task Start() {
        FirstSync();
        await SecondAsync();

        AsyncVoidThird();

        try {
            ForthSync();
        }
        catch {}

        try {
            await FithAsync();
        }
        catch {}
    }

    [Trace]
    private static void FirstSync() {}

    [Trace]
    private static void ForthSync() {
        throw new Exception("boom!");
    }

    [Trace]
    private static async void AsyncVoidThird() {
        await Task.Delay(1000);
        Console.WriteLine("AsyncVoidThird done.");
    }

    [Trace]
    private static async Task SecondAsync() {
        await Task.Delay(1000);
        Console.WriteLine("SecondAsync done.");
    }

    [Trace]
    private static async Task FithAsync() {
        await Task.Delay(1000);
        throw new Exception("async boom!");
    }
}

internal class Program {

private static void Main(string[] args) {

Start().Wait();

Console.WriteLine("All done");

Console.ReadKey();

}

private static async Task Start() {

FirstSync();

await SecondAsync();

AsyncVoidThird();

try {

ForthSync();

}

catch {}

try {

await FithAsync();

}

catch {}

}

[Trace]

private static void FirstSync() {}

[Trace]

private static void ForthSync() {

throw new Exception("boom!");

}

[Trace]

private static async void AsyncVoidThird() {

await Task.Delay(1000);

Console.WriteLine("AsyncVoidThird done.");

}

[Trace]

private static async Task SecondAsync() {

await Task.Delay(1000);

Console.WriteLine("SecondAsync done.");

}

[Trace]

private static async Task FithAsync() {

await Task.Delay(1000);

throw new Exception("async boom!");

}

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

Подробнее

Async/Await для .Net 4.0 Video

01.11.201206.11.2012 по koissakh kadderah

Сложность 200-400

Буквально на днях в блоге разработчиков Base Class Library промелькнуло известие о том, что теперь можно использовать async/await и для кода написанного на .Net Framework 4. А это значит можно использовать удобный подход для асинхронной работы, даже если пользователи вашей программы до сих пор сидят на «старой, доброй XP» по тем или иным причинам. Естественно такая новость не могла пройти мимо меня, чтобы я не попробовал как оно на самом деле в использовании. Забегая вперед, и что вполне ожидаемо, работает все точно так же как и в 4.5 за исключением некоторых нюансов в процессе разработки.

Процесс работы с новыми возможностями показан на видео подкатом.

Hard’n’Heavy!

Async/Await для .Net 4.0

31.10.201229.10.2012 по koissakh kadderah

Сложность 200-400

Команда разработчиков анонсировала пакет дополнений, который позволяет использовать await в Visual Studio 2012 (в предыдущих версиях работать не будет). Выпущенный пакет может быть применен к следующим платформам (указанной версии или выше):

.NET Framework 4.0 (with KB2468871)
Silverlight 4
Windows Phone 7.5
И портируемые библиотеки опирающиеся на указанные платформы.

Т.е. это не встроенная фича .net 4.5?

И да и нет. Очень заманчиво думать, что новые ключевые слова await/async в C# являются чистым новым функционалом языка. В некоторой степени это так: компилятору необходимо проделать достаточно много сложной работы с вашим кодом, чтобы он мог ожидать операции.

Принимая вышесказанное во внимание, разработчики ожидают возможность использования await как только они переходят на новую студию – независимо от платформы языка. Если вы задумывались о том, как реализовано большинство фич языка, то вы можете догадаться, что многие вещи не просто данность и особенность языка. Множество конструкций языка опираются на вполне конкретные API, к примеру, методы расширения опираются на ExtensionAttribute, а foreach зависит от интерфейса IEnumerable. В случае с await потребуется давно любимый класс Task и некоторая хитрая обвязка, которая делает возможным использование await.

Подробнее

PostSharp Thread\Dispatcher Toolkit

03.10.201230.09.2012 по koissakh kadderah

Сложность 100

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

Итак, сегодня в программе тулкит, который позволяет с помощью атрибутов указать выполнение метода в отдельном потоке, а так же указать какие методы вызывать в потоке UI. Собственно вот и весь функционал.

О том как решаются эти проблемы в «традиционном» стиле, я рассказывал в статье про эволюцию сервисных методов, там же описана библиотека MakeMeAsync, которой я с удовольствием и активно пользуюсь на данный момент. Не буду повторятся какие альтернативы существуют. Сейчас уже официально выпущен .Net Framework 4.5 c поддержкой конструкции async\await, так что я надеюсь что использование монструозных конструкций для выполнения кода асинхронно будет сходить на нет.

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

Подробнее

Make me async

14.05.201213.06.2012 по koissakh kadderah

Сложность 200

Почти месяц назад я написал статью «Эволюция сервисных методов». В ней я пришел к реализации библиотеки MakeMeAsync, которая позволяет декорировать вызовы методов, делая их асинхронными. При этом код остаётся максимально читабельным и чистым, на мой взгляд.

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

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

Итак, я думаю, что для начала стоит обновить информацию о том, как используется библиотека MakeMeAsync.

Подробнее