Sentinel's bLog

Я.Субботник в Санкт-Петербурге, 3 декабря

2011-11-29T19:44:00.001+04:00

Я.Субботник в Санкт-Петербурге пройдет 3 декабря в офисе Яндекса.

Регистрация на мероприятие начнется 23 ноября. Количество мест ограничено.

Для тех, кто не попадёт в число участников или не сможет лично присутствовать на Я.Субботнике, будет организована онлайн-трансляция.

Подробную информацию о мероприятии читайте здесь.

Асинхронное программирование и C# 5.0

2010-10-31T16:47:00.001+03:00

На PDC 2010 были анонсированы асинхронные функции в C# и VB.NET. Рассказ о них хочется начать историей эволюции C# Эрика Липперта:

Проектировщики С# 2.0 осознали мучительность процесса написания логики работы итератора. Так были введены блоки итераторов (iterator blocks). Это был способ дать понять компилятору как построить конечный автомат для хранения продолжения (continuation) - “что будет дальше” – в состоянии где-то внутри, скрытом за кулисами, так чтобы больше не приходилось описывать это в коде.

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

Проектировщики С# 3.0 поняли сложность написания кода, выполняющего сортировку, фильтрацию, объединение, группирование или обобщение сложных данных, поэтому и были добавлены выражения запроса (query comprehensions) и все остальные возможности LINQ. Тем самым компилятор научился делать правильные вызовы объектной модели для построения запроса, деревьев выражений и всего остального.

Проектировщики С# 4.0 поняли трудность взаимодействия как с современной, так и со старой динамической объектной моделью, поэтому и был добавлен тип dynamic. Так компилятор научился генерировать во время компиляции код, который будет обрабатываться в Dynamic Language Runtimeво время выполнения.

Проектировщики C# 5.0 поняли сложность написания асинхронного кода: его трудно понять, преобразование в continuation сложно и насыщает код вспомогательными механизмами, делающими неясным его назначение.

Так больше не могло продолжаться.

Итак, что же мы получили и зачем?

Microsoft Visual Studio Async CTP представила новые языковые возможности для C# и VB и новые паттерны, позволяющие выполнять асинхронное программирование подобно и почти так же прямолинейно, как и синхронное.

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

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

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

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

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

Нововведения в C#

С выходом Async CTP мы получили Community Technology Preview прототипа компилятора C# 5.0. Это именно прототип, предварительная версия для знакомства с новыми возможностями и в будущем все может измениться, даже синтаксис.

C# 5.0 вводит два новых ключевых слова await и async для реализации асинхронных функций в C#. В двух словах, модификатор async помечает метод или лямбда-выражение как асинхронные. Оператор await прекращает работу до тех пор, пока не будет завершена ожидаемая задача.

Другими словами, синхронный код:

загрузить данные, подождать результата, обработать, подождать окончания, сохранить результат, подождать…

преобразуется в асинхронный:

начать загрузку данных, когда будет закончено, начать обработку данных, когда будет закончено, начать сохранение результатов, когда результаты будут сохранены…

То есть, за счет введения двух новых ключевых слов типичный императивный код (сделай это, потом сделай то) преобразуется в декларативный (делай это, когда закончишь делай то). За декларативным асинхронным программированием стоит явное намерение эффективного использования доступных ресурсов. Anders Hejlsberg пообещал что wait+async это первые шаги для поддержки параллельного программирования на уровне языка.

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

Рекомендуемый паттерн в .NET для реализации асинхронных функций, возвращать задачу, представляющую выполняемую операцию и позволяющую ожидать ее окончания в какой-то момент времени. Асинхронные функции – это новая возможность в C#, предоставляющая упрощенные средства для выражения асинхронных операций.

Небольшой пример:

Task<Movie> GetMovieAsync(string title);

Task PlayMovieAsync(Movie movie);

async void GetAndPlayMoviesAsync(string[] titles)

    foreach (var title in titles)

        var movie = await GetMovieAsync(title);

        await PlayMovieAsync(movie);

По соглашению, асинхронные операции используют суффикс “Async”, чтобы показать, что частично их выполнение может быть произведено после возврата из метода. И GetMovieAsync, и PlayMovieAsync возвращают задачу, что обозначает, что их окончание в последствии можно ожидать. В противоположность этому GetAndPlayMoviesAsync возвращает void, так что ожидание его окончания (через await) невозможно. Подобные асинхронные операции часто называют как “запустил и забыл” и могут быть полезны например для реализации асинхронных обработчиков событий.

GetAndPlayMoviesAsync помечен модификатором async как асинхронная функция, содержащая два await-выражения. Этот факт сообщает вызывающему о деталях реализации метода и фундаментально изменяет способ, которым метод выполняется: как только незавершенная задача (Task) начнет ожидание, управление будет возвращено вызывающему. Когда ожидаемая задача (Task) завершится, выполнение метода GetAndPlayMoviesAsync возобновится, до ожидания следующей незавершенной задачи и т.д. В промежутках между ожиданиями незавершенных задач, не занимается никакой дополнительный поток на выполнение этого метода, время “занимается” только в моменты активности.

Прежде чем двигаться дальше хочу прояснить частое заблуждение, связанное с понятием асинхронности.

Асинхронность не является синонимом “параллелизма” (concurrency) (одновременного (параллельного) выполнение компьютером нескольких операций), она может быть реализована с использованием этого подхода, но это не является обязательным. Другой пример реализации асинхронности – это разбиение начальной задачи на небольшие части, объединение их в очередь и затем выполнение обработки, когда поток не занят чем-то другим.

Итак, новые ключевые слова: await - указывает, что вызывающий хочет получить управление, когда вызов асинхронного метода будет завершен, async – это модификатор для метода или анонимной функции, показывающий, что они являются асинхронными. Функции без этого модификатора считаются синхронными.

Несколько замечаний:

Модификатор метода async не означает, что “данный метод будет автоматически запланирован к запуску в рабочем потоке асинхронно”. Он обозначает прямо противоположное, “этот метод содержит управляющую логику, связанную с ожиданием асинхронных операций и тем самым будет перезаписан компилятором в стиле передачи продолжений (continuation passing style) для гарантии того, что асинхронные операции смогут продолжить выполнение этого места с корректной точки”. Главная особенность асинхронных методов состоит как раз в том, чтобы оставаться в текущем потоке как можно дольше. Они подобны сопрограммам (coroutines): асинхронные методы добавляют однопоточную кооперативную многозадачность в C#.
Оператор await не обозначает “эта операция блокирует текущий поток до возврата из асинхронной операции”. Это превратило бы асинхронные операции в синхронные, чего собственно и хотелось избежать. Смысл же противоположный: “если задача, которую мы ожидаем еще не завершена, то запишем остальную часть метода как продолжение этой задачи и сразу вернемся к вызывающему; задача продолжится (будет вызвано продолжение) по завершению асинхронной операции”.
Во время выполнения асинхронная функция может быть в одном из трех состояний: выполняется, приостановлена на await или выполнена.

“Путанница”

Исходный документ ((CSharp Spec) Asynchronous Functions) меня несколько ввел в заблуждение, возникло впечатление, что новый функционал полностью завязан на Task. Однако, благодаря Reed Copsey, Jr., Jon Skeet и собственным экспериментам, удалось понять, что это не так.

Нововведения разделю на две части: изменения в языке и изменения в Framework.

Изменения в языке

Грамматика C# была расширена await-выражениями, используемыми для приостановки выполнения асинхронной функции, пока ожидаемая задача не будет выполнена. await-выражения допускаются только в теле асинхронных функций. Внутри асинхронной функции выражение не может использоваться в теле синхронной функции, в catch или finally блока оператора try, внутри lock или в небезопасном (unsafe) контексте. Однако, внутри самого try и, как следствие, в using вполне допустимы.

Шаблон await

Выражение t await-выражения “await t” называется задачей (это просто термин, не относящийся к типу Task) выражения. Задача t должна позволять ожидание (быть awaitable), что означает выполнение следующих условий:

(t).GetAwaiter() должно быть верным выражением типа A.
Для данного выражения a типа A и выражения r типа System.Action выражение (a).BeginAwait(r) должно быть верным логическим выражением.
Для заданного выражения a типа A, (a).EndAwait() должно быть верным выражением.

A называется ожидающим (awaiter) типом await-выражения. Метод GetAwaiter используется для получения awaiter-типа для задачи.

Метод BeginAwait используется для записи продолжения ожидающей задачи. Продолжение передаваемое в качестве параметра является делегатом возобновления.

Метод EndAwait используется для получения результата выполнения задачи, после ее завершения.

Вызовы методов разрешаются синтаксически, то есть GetAwaiter, BeginAwait и EndAwait могут быть как членами экземпляра, так и методами расширениями (extension) или даже привязанными динамически, главное чтобы вызов был верным в контексте await-выражения. Подразумевается, что все они должны быть “неблокирующими”, то есть не приводят к значительному ожиданию вызывающего потока, например окончания завершения операции.

await-выражение классифицируется так же как и выражение (a).EndAwait(), то есть:

если выражение (a).EndAwait() вызывает метод или делгат, возвращающий тип void, то результатом и будет void.
в противном случае результат будет того типа, который возвращает (a).EndAwait().

Вычисление await-выражений

Во время выполнения тела асинхронной функции await t вычисляется следующим образом:

awaiter a получается путем вычисления выражения (t).GetAwaiter()
вычисляется логическое выражение (a).BeginAwait(r), где r – делегат, первое выполнение которого приведет к тому, что заключенная в выражении асинхронная функция будет продолжена с текущего await-выражения.
если результатом логического выражения является true вычисление приостанавливается и управление возвращается методу, который вызвал или возобновил выполнение асинхронной функции.
затем (или сразу, или во время возобновления) вычисляется выражение (a).EndAwait(). Если оно возвращает какое-то значение, то это значение и становится await-выражения.

Метод BeginAwait либо возвращает false, чтобы показать, что задача уже завершена, либо true, чтобы показать, что делегат r необходимо вызвать, когда задача в конце концов завершится. Возврат false позволяет выполнять ожидание (await) уже завершенных задач, предотвращая приостановку выполнения только для того, чтобы сразу оно было возобновлено.

Если BeginAwait возвращает true, то awaiter должен позаботиться о том, чтобы делегат r был вызван не больше раза.

Если BeginAwait возвращает false, то awaiter должен удостовериться, что делегат r не будет вызван ни разу. Если r не смотря на ограничения будет вызван, то поведение не определено.

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

На практике это означает, что на уровне компилятора нет никакой привязки к задачам (Task), все что надо, это реализация в классе или в расширениях трех методов: GetAwaiter, BeginAwait и EndAwait, и этого будет вполне достаточно для того, чтобы воспользоваться новым механизмом. Подробнее о разрешении методов можно почитать в статье Jon Skeet: C# 5 async: experimenting with member resolution (GetAwaiter, BeginAwait, EndAwait)

По существу, новые методы реализуют вполне привычную программную модель работы с асинхронными методами (Asynchronous Programming Model) с разделением задачи на Begin/End методы и методом обратного вызова для сигнализации окончания выполнения. Основное отличие в том, что теперь генерация подобных “оберток” делается компилятором автоматически.

В подавляющем большинстве случаев, для практического применения “ручного” задания класса, с соответствующим интерфейсом не потребуется, так как для большинства задач, в которых применение нового асинхронного шаблона имеет смысл (например, задачи ввода/вывода, сложные расчетные задачи), удобно реализовывать с помощью нового для .NET 4 Task из Task Parallel Library, а await-выражения с Task поддерживаются непосредственно, без необходимости писать дополнительный код. Так же в Framework добавлено множество расширений стандартных классов возвращающих Task<TResult> в качестве результата, что позволяет так же использовать эти методы непосредственно в await.

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

class Awaiter

    public Awaiter GetAwaiter()

        return this;

    public bool BeginAwait(Action continuation)

        return true;

    public void EndAwait()

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

На всякий случай замечу, никто не заставляет повторять вручную и писать собственные реализации с Task для работы с асинхронными функциями вместо тех, что предоставляет Framework. Но понимать, происходящие внутри процессы весьма важно. Именно, поэтому я на них специально остановился. За более подробными примерами можно обратиться к статье Jon Skeet: C# 5 async: investigating control flow

Что делает компилятор?

На самом деле, компилятор выполняет обработку сильно напоминающую обработку для итераторов (yield return).

Асинхронный метод – это не обычный последовательный метод, он преобразуется в конечный автомат (объект) с некоторым набором состояний (локальные переменные становятся полями этого объекта), каждый блок кода между последовательными использованиями await является одним “шагом” автомата.

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

Для примера, следующий код:

async Task TestAsync()

    var var1 = F();

    var var2 = await FAsync();

    more(var1, var2);

Будет преобразован в нечто подобное:

class _TestAsync

  int _var1, _var2;

  int _state = 0;

  Task<int> _await1;

  public void DoStep()

    switch(_state)

        case 0:

          _var1 = F();

          _await1 = FAsync();

          _state = 1;

SetContinuation(DoStep); // По завершению асинхронной операции необходимо вызвать этот же метод

          case 1:

      // Получение результата операции
      _var2 = _await1.Result;

   more(_var1, _var2);

Важным здесь является использование метода SetContinuation(), для указания что когда операция будет завершена, необходимо вызвать еще раз метод DoStep(), а за счет того, что состояние изменилось (переменная _state), при повторном вызове будет выполнена вторая часть метода (case 1).

Данное преобразование очень близко к аналогичному для итераторов и на деле, одним из приемов для упрощения работы с асинхронными методами и является их использование. Для примера, можно вспомнить библиотеку PowerThreading от Jeffrey Richter или статью Asynchronous Programming in C# using Iterators, где рассматриваются схожие идеи.

На самом деле, преобразование несколько сложнее так как помимо продолжения операции необходимо, например, учитывать возможные исключения в процессе работы. Примеры преобразований приведены в конце новой спецификации ((CSharp Spec) Asynchronous Functions (документация Async CTP)), посмотрите на раздел Implementation example, колонку Syntactic expansion. Кроме этого, можно просто скомпилировать какой-нибудь пример и глянуть результат Reflector’ом.

Изменения в Framework

Для упрощения перехода на новую модель команда разработки Async CTP расширила с использованием нового подхода класс Task, представив новый шаблон Task-based Asynchronous Pattern (TAP) (Асинхронный шаблон проектирования на основе задач), подробности можно прочитать в документах Asynchrony in .NET и The Task-based Asynchronous Pattern (находятся в каталоге документации после установки Async CTP). На данный момент они находятся в сборке AsyncCtpLibrary.dll.

Еще раз обращаю внимание: расширение класса Task и асинхронные решения на его основе, являются дополнением Framework, а не компилятора и призваны упростить миграцию кода в соответствии с новым подходом. Для компилятора нет разницы используется ли класс Task или другой класс, при условии следования описанным правилам. Но реальная реализация большинства новых методов, выполнена за счет расширения класса Task методом GetAwaiter(), возвращающим структуру TaskAwaiter и для дальнейшей работы используются уже её методы BeginAwait и EndAwait.

Почему за основу взят именно класс Task?

Причина заключается в том, асинхронность не требует параллелизма, но параллелизм требует асинхронности и многие инструментальные средства полезные для параллелизма могут быть так же легко использованы для непараллельной асинхронности. В Task нет неотъемлемого присутствия параллелизма, Task Parallel Library (TPL) использует шаблон на основе задач для представления частей выполняющейся задачи, которые могут быть распараллелены, не требуя многозадачности.

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

В класс Task из TPL вложено очень многое: у него есть механизм отмены (cancellation) и другие полезные возможности. Вместо изобретения чего-то нового наподобие “IFuture”, просто был расширен существующий код для удовлетворения асинхронным потребностям.

AsyncCtpLibrary включает в себя множество extension-методов для существующих в Framework классов, с тем, чтобы предоставить асинхронные варианты существующих методов. По соглашению, эти методы названы с суффиксом Async, например CopyToAsync для асинхронного копирования потока. В случае, если в классе был уже метод с суффиксом Async, то для избежания путаницы в таких классах методы имеют суффикс TaskAsync, например, DownloadDataTaskAsync. Все эти методы приведены в соответствие требованиям для возможности использования вместе с await.

Сам класс Task так же был расширен (структура TaskAwaiter), чтобы позволять своё использование с await. Кроме того, “пригодились” и изначально заложенные в TPL возможности по взаимодействию с существующей асинхронной моделью, семейство методов TaskFactory.FromAsync, использующихся для конструирования Task из пары Begin/End методов “старой” модели асинхронного программирования (Asynchronous Programming Model).

Помимо расширений для классов Framework для возможности использования с await, добавились и дополнительные методы, например, Yield, используется, чтобы временно прервать выполнение, позволяя продолжиться другим операциям, SwitchTo используется для переключения контекста (SynchronizationContext) выполнения операции. Например,

public async void button1_Click(object sender, EventArgs e)

    string text = txtInput.Text;

    await ThreadPool.SwitchTo(); // переключение в ThreadPool

    string result = ComputeOutput(text);

    string finalResult = ProcessOutput(result);

    await txtOutput.Dispatcher.SwitchTo(); // переключение в поток TextBox

    txtOutput.Text = finalResult;

Нововведений довольно много, в короткой заметке все не охватить за примерами, приемами работы и самое главное подробностями рекомендую обратиться к The Task-based Asynchronous Pattern от Stephen Toub, где они весьма неплохо рассмотрены.

Как это работает на уровне Task (Task-based Asynchronous Pattern)?

Async CTP помимо нововведений в язык, ориентирована на использование нового механизма непосредственно с TPL, поддерживая await-выражения непосредственно над Task.

На уровне API неблокирующее ожидание достигается за счет предоставления методов обратного вызова (callbacks), вызываемых после завершения операции. Для задач (Task) это же достигается для счет методов типа ContinueWith. Поддержка асинхронного подхода в языке прячет обратные вызовы, позволяя асинхронным операциям ожидать окончания выполнения в обычном порядке за счет генерируемого компилятором кода.

Как я уже писал, await непосредственно поддерживает асинхронное ожидание Task и Task<TResult>. На данный момент это достигается за счет соответствующих методов расширения Task (см. структуру TaskAwaiter), а не компилятором непосредственно. Для Task результат await-выражения - void, для Task<TResult> – результат TResult.

“Внутри”, для поддержки функционала await устанавливается метод обратного вызова на задачу через продолжение. Этот метод продолжит выполнение асинхронного метода с точки остановки. Когда выполнение асинхронного метода будет возобновлено, если задача Task<TResult> находилась в ожидании и завершилась успешно, то будет возвращен TResult.

Если выполнение Task или Task<TResult> завершилось состоянием отмены (Canceled state), то будет выброшено исключение OperationCanceledException.

Если выполнение Task или Task<TResult> завершилось состоянием сбоя (Faulted state), то будет выброшено соответствующее исключение, вызвавшее его. Возможно, что сбой будет вызван множеством исключений, в этом случае только одно из них будет выброшено, однако свойство Exception в Task будет содержать AggregateException, содержащий все ошибки.

Если с потоком, выполняющим асинхронный метод, был ассоциирован SynchronizationContext на момент приостановки (другими словами SynchronizationContext.Current не null), возобновление работы асинхронного метода будет произведено в том же SynchronizationContext за счет метода Post. В противном случае, возобновление будет зависеть от текущего System.Threading.Tasks.TaskScheduler на момент приостановки (как правило это TaskScheduler.Default, соответствующий .NET ThreadPool). Окончательное решение: разрешить возобновление непосредственно по окончанию выполнения асинхронного метода, или запланировать возобновление выполнения на будущее за TaskScheduler .

В момент вызова асинхронный метод выполняет тело метода синхронно до первого await-выражения, в этой точке он возвращает управление вызывающему. Если асинхронный метод не возвращает void, то результатом будет Task или Task<TResult>, представляющие продолжающиеся вычисления (напомню, в данный момент речь о поведении Framework-методов, а не компилятора в целом).

После выполнения первого await-выражения, оставшаяся часть тела метода эффективно выполняется одновременно (параллельно) с кодом, вызвавшем асинхронный метод. Когда же ожидаемая операция в теле метода завершится, начинается выполнение следующей части метода. Если встречается оператор return или будет достигнут конец асинхронного метода, задача (Task) считается завершенной в состоянии RanToCompletion. Если будет выброшено необработанное исключение, прерывающее выполнение метода (выход за тело асинхронной функции), задача завершается состоянием Faulted (если это исключение OperationCanceledException, то вместо этого задача будет в состоянии Canceled). В любом из вариантов, будет либо возвращен результат операции, либо исключения помешавшие этому.

Существует несколько важных отличий от описанного поведения. Для повышения производительности, в случае если задача уже завершила работу к моменту начала ожидания, переключения управления не будет производиться, а вместо этого сразу же продолжится выполнение метода. Кроме того, не всегда удобно и необходимо переключаться в тот же контекст из которого было начато ожидание. Подробнее об этом можно почитать у Stephen Toub в The Task-based Asynchronous Pattern (документация Async CTP).

TPL Dataflow

Еще одно интересное добавление. TPL Dataflow (TDF) построена поверх функционального уровня TPL и дополняет его набором примитивов, для решения более сложных задач чем исходная библиотека. TDF использует задачи, потоково-безопасные коллекции и другие возможности, представленные в .NET 4 для добавления поддержки параллельной обработки параллельного потока данных. Она так же непосредственно интегрируется с новой поддержкой в языке асинхронного программирования.

Многие программные системы ориентированы на обработку потоков данных. Эти потоки данных часто большие или даже бесконечные, и/или требуют сложной обработки, приводя к потребностям в высокой скорости обработки и потенциально к очень большой вычислительной нагрузке. Чтобы справится с этими требованиями, были введены средства для распараллеливания обработки на доступные системные ресурсы, например, несколько ядер. Однако, модель параллельного программирования в сегодняшнем .NET Framework’е (включая .NET 4) не была разработана с мыслью о потоках данных, приводя к усложнению кода, низкоуровневым блокировкам и т.п., в итоге уменьшая производительность системы, вводя проблемы с параллелизмом, которых можно было бы избежать в случае выбора модели более подходящей реактивным системам.

TDF привносит несколько ключевых примитивов в TPL, позволяющих разработчикам описывать обработку основанную на графах потоков данных. Данные всегда обрабатываются асинхронно. С этой моделью нет необходимости явно запускать задачи для обработки, разработчики декларативно описывают зависимости между данными и среда выполнения планирует обработку основанную на асинхронном поступлении данных и описанных зависимостях. Таким образом, TDF генератор для задач (Task) подобно классу Parallel в PLINQ, но Parallel и PLINQ специализируются на более структурированной модели параллельных вычислений, а TDF специализируется на неструктурированной асинхронной модели.

Есть некоторое подобие между TDF и Rx. Но если Rx преимущественно специализируется на координировании и композиции потоков событий с API основанном на LINQ, предоставляя богатый набор комбинаторов для манипулирования данными IObservable<T>. В противоположность этому, TDF специализируется на строительных блоках для передачи сообщений и распараллеливания в процессорно- и IO-нагруженных приложениях, предоставляя при этом разработчикам явный контроль надо тем как данные буферизируются и перемещаются внутри системы.

Пример:

Класс ActionBlock<TInput> можно воспринимать логически как буфер данных, которые необходимо обработать вместе с задачами по обработке. В большинстве случаев можно просто создать экземпляр класса и “отправить” ему данные, делегат указанный при создании ActionBlock, будет асинхронно выполняться для каждого отправленного набора данных.

var ab = new ActionBlock<TInput>(delegate(TInput i)

    Compute(i);

});

…

ab.Post(1);

ab.Post(2);

ab.Post(3);

Второй пример:

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

private static BufferBlock<int> m_buffer = new BufferBlock<int>();

// Производитель

private static void Producer()

    while(true)

        int item = Produce();

        m_buffer.Post(item);

// Потребитель

private static async Task Consumer()

    while(true)

        int item = await m_buffer.ReceiveAsync();

        Process(item);

TDF очень интересна, рекомендую почитать более подробно о ней в документации.

Jeffrey Richter’s AsyncEnumurator и Async CTP

В своей рассылке, посвященной PowerThreading, Jeffrey Richter прокомментировал новый Async CTP. Переведу от его лица.

Я был серьёзно вовлечен в создание новых асинхронных возможностей, которые Microsoft добавила в следующие версии C#/VB.

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

По существу, новая возможность языка очень похожа на итераторы C# с тем исключением, что вместо ‘yield return’ используется await. Новое ключевое слово более естественно и может использоваться для выражения контекста, в противоположность операторному содержимому (yield return), который просто упрощает ваш код, улучшая его компоновку. Кроме того, асинхронные методы могут вызывать другие асинхронные методы, что является огромным улучшением по сравнению с тем, что вам позволяли делать итераторы. Это позволяет вам иметь асинхронные подпрограммы, которые можно вызывать из других асинхронных (и не асинхронных) методов для улучшения структуры. Мой AsyncEnumerator так же поддерживает это, но довольно топорно.

Новые асинхронные возможности сконцентрированы на Task, что предоставляет три больших преимущества. Во-первых, это намного проще использования Begin/End/IAsyncResult. Во-вторых, это объединяет выполнение вычислительных операций и операций ввода/вывода вокруг единственной конструкции. В-третьих, они интегрируют работу с SynchronizationContext, что само по себе является большим улучшением по сравнению с Begin/End. Все это снижает сложность понимания концепции программистами и делает принципы работы более естественными. Кроме того, я не знаю собирается ли MS официально объявлять устаревшей или неподдерживаемой асинхронную модель на основе событий (event-based APM) (наподобие классов BackgroundWork и WebClient), но они непременно должны воспрепятствовать использованию этих классов людьми, использующими шаблоны на основе событий. Этот шаблон всегда имел множество проблем и я твёрдо уверен, что он вообще не должен использоваться. Новые асинхронные возможности намного лучше всего, что может предложить событийный подход.

Что касается AsyncEnumerator:

Он работает на .NET 2.0 и выше. Новые асинхронные возможности не будут работать на этих платформах, по факту они еще даже не выпущены.

Мне необходимо подробнее изучить детали, но я практически уверен, что новые асинхронные возможности имеют немного большие накладные расходы (overhead) по сравнению с AsyncEnumerator. С новыми возможностями вы создаете Task (объект с большим количеством полей в нем), оборачивая существующие в Framework Begin/End. То есть заканчиваете тем, что выделяете больше памяти и выполняете вызов вызова. Для людей, которые действительно беспокоятся о памяти/производительности, я практически уверен, что мой AsyncEnumerator использует меньше памяти и выполняется быстрее. Я не делал еще никаких исследований, чтобы привести конкретные числа.

Мой AsyncEnumerator по-прежнему предлагает некоторые возможности, которых нет в асинхронных нововведениях. Например, поддержка отладки в AsyncEnumerator гораздо лучше. AE так же дает вам возможность перехватывать события приостановки/возобновления в конечном автомате, это потребовалось для некоторых из моих клиентов для переноса состояния между потоками в процессе переключения конечного автомата с потока на поток. Я так же предоставляю способ не использовать SynchronizationContext, так что часть работы может быть выполнена в потоке GUI, а часть в рабочем потоке (прим. такая возможность есть и у await/async). Новый асинхронный функционал всегда использует SynchronizationContext. Наконец, в некоторых случаях кодирование с использованием AE немного проще. Для примера, с использованием AE вы можете легко ждать окончания ‘n’ операций, в нововведении вам придется использовать методы-комбинаторы.

Мне нравятся нововведения и это абсолютно точно правильное направление движения. Помните, что прямо сейчас они находятся в зародыше и в будущем команда добавит более хорошую поддержку отладки и другие возможности. Мой AsyncEnumerator будет оставаться доступным для всех кому потребуется поддержка .NET 2.0 и старше и я продолжу адаптировать его к новым возможностям C#/.NET, так чтобы людям не пришлось портировать весь свой код на новую модель. Я попробую улучшить новые асинхронные возможности лучшей поддержкой отладки и всем остальным, что предлагает AE на сегодняшний день. Я чувствую себя крайне ответственным перед пользователями AsyncEnumerator и собираюсь продолжать работу над ним. К тому же, я безусловно быстрее чем Microsoft смогу ответить на запрос и добавить новые возможности или исправления ошибок.

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

Async CTP и R#

В ReSharper поддержки для нового Async CTP пока не будет. Безусловно, поддержка для нового C# будет разрабатываться, когда он хоть как-то будет стандартизирован, в данный момент об этом говорить еще рано, так как все может еще поменяться, даже синтаксис.

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

Проблема, не том, что придется поправить синтаксический анализатор, и даже не столько в том, что придется повторить работу компилятора, для соответствующей трансформации исходного кода. R# работает со “сломанным” исходным кодом, выполняя его анализ и обработку, придется внести существенные изменения в эти алгоритмы, а поскольку все еще может измениться, то это было бы довольно непрактичным.

Информация по теме (или с чего начать?)

Visual Studio Async CTP (Страница загрузки)

The Future of C# and Visual Basic (PDC10 session by Anders Hejlsberg)

Asynchronous Programming for C# and Visual Basic (MSDN)

Visual Studio Async CTP Forum

C# Language Specification for Asynchronous Functions - (CSharp Spec) Asynchronous Functions (документация Async CTP)

Asynchrony in .NET

Stephen Toub, The Task-based Asynchronous Pattern (документация Async CTP)

Установка Async CTP и начало работы, так же советую после установки заглянуть в документ Walkthrough: Getting Started with Async (документация Async CTP)

Блог Эрика Липперта по теме асинхронного программирования

Дмитрий Нестерук - Async CTP: Async, Await и C#5

Reed Copsey: C# 5 Async, Part 1: Simplifying Asynchrony – That for which we await

Jon Skeet: Initial thoughts on C# 5's async support

Anoop Madhusudanan: C# 5.0 Asynchrony – A Simple Intro and A Quick Look at async/await Concepts in the Async CTP

TPL With Other Asynchronous Patterns – использование TPL с другими асинхронными шаблонами.

Introduction to TPL Dataflow (документация Async CTP)

Видео от ключевых разработчиков: Mads Torgersen, Lucian Wischik и Stephen Toub

Интереснейшая серия статей по сравнению концепций асинхронного программирования в F# и C# от Tomas Petricek- Asynchronous C# and F# (I.): Simultaneous introduction

Обещанный пример консольного приложения, реализующего шаблон await-выражений, поддерживаемый новым компилятором. Ценность этого примера весьма сомнительна, но тем не менее, он позволит вам изучить, например, с помощью Reflector как именно производится трансформация исходного кода. Не забудьте добавить в References AsyncCtpLibrary.dll, чтобы не обижать компилятор.

using System;

namespace AsyncTesters

    class Program

        class Awaiter

            private Action _continuation;

            public Awaiter GetAwaiter()

                Console.WriteLine("Init awaiter");

                return this;

            public bool BeginAwait(Action continuation)

                Console.WriteLine("Begin await: {0}", continuation.Method.Name);

                _continuation = continuation;

                return true;

            public void EndAwait()

                Console.WriteLine("End await");

            public void Continue()

                _continuation();

        async static void Test(Awaiter s)

            Console.WriteLine("Start testing");

            await s;

            Console.WriteLine("End testing");

        static void Main(string[] args)

            var awaiter = new Awaiter();

            Test(awaiter);

            Console.WriteLine("Test returns");

            awaiter.Continue();

            Console.ReadLine();

После запуска на консоль должно вывестись:

Start testing
Init awaiter
Begin await: MoveNext
Test returns
End await
End testing

Повторюсь, особой практической ценности пример не несет, разве что демонстрирует идею использования нового механизма в компиляторе. За более подробными примерами можно обратиться к статье Jon Skeet: C# 5 async: investigating control flow

Удачи!

Улучшение справочной системы Visual Studio 2010

2010-04-22T22:48:00.001+04:00

Справочная система в новой Visual Studio 2010 с одной стороны сделала большой шаг вперед – новое, отлично проработанное API (MS Help 3 / Microsoft Help Viewer 1.0), с другой стороны - идущая в комплекте программа просмотра очень многих не устроила.

Microsoft утверждает, что просто не успела привести его к соответствующему виду:

A number of VS 2010 Beta 2 customers have asked why we did not deliver a Keyword Index as part of the new help system. We realize the importance of delivering a keyword index, but we were unable to deliver it in our first release. In this V1.0 release of help system, we first implemented an improved search capability in order to deliver a more familiar, consistent online and offline experience. We then implemented a keyword index feature based on our search catalog. Unfortunately, the results did not meet our quality bar and we determined that this feature would require more work than the Beta 2 timeline allowed. We are looking at implementing it for at future release.

К счастью, решение все же есть и не одно.

Первый вариант поставить расширение Keyword Index for Visual Studio 2010 Help Documentation , написанное Ryan Linton и позволяющее просматривать непосредственно в VS IDE.

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

Второй вариант – воспользоваться MS Help 3 Viewer , разработанный Rob Chandler, который позволит работать со справкой в привычном для Visual Studio 2008 виде :

Справка по программе

Ссылки по теме:

Help is missing an index - Отзыв на Microsoft Connect.

The Helpware Group – подборка информации и утилит по новой справочной системе, раздел, посвященный новому формату

Блог Rob Chandler (Helpware Blog)

Описание HelpViewerKeywordIndex VS 2010 Ext

MS Help 3 Viewer by The Helpware Group

Shrinkr – проект с открытым исходным кодом для сокращения длины ссылок (URL) на основе ASP.NET MVC 2

2010-04-21T01:42:00.001+04:00

Shrinkr – это ASP.NET MVC 2 проект с открытым, который можно использовать как демонстрацию подхода при разработке с использованием следующих инструментов:

.Net Framework 4.0;
ASP.NET MVC 2 ;
jQuery 1.4.2 ;
Entity Framework 4 с использованием модели Code Only;
AspNetMvcExtensibility – проект с открытым исходным кодом, содержащий универсальные, готовые к использованию компоненты, разработанные с использованием рекомендуемого подхода для ASP.NET MVC;
Telerik Extensions для ASP.NET MVC ;
DotNetOpenAuth 3.4 для поддержки аутентификации через OpenID, OAuth;
Elmah - (Error Logging Modules and Handlers) – для ведения журнала работы (лога) и обработки исключений;
MoQ 4 - mock framework в модульных тестах (unit tests);
xUnit 1.5 – framework для модульного тестирования.

Сервис можно посмотреть “вживую” тут

Подробнее:

Shrinkr на CodePlex

Releasing Shrinkr – An ASP.NET MVC Url Shrinking Service

Introducing Shrinkr The URL Shrinking Service built with ASP.NET MVC 2

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

Преобразование Windows Forms в XAML (WF2XAML)

2010-04-20T22:18:00.001+04:00

Вышла новая (0.6.0.0 BETA) версия конвертора WF2XAML.

Windows Forms to XAML Converter (WF2XAML) – это утилита для преобразования Windows Forms в WPF/Silverlight/Windows Phone XAML. Она основана на концепции шаблонов и, по словам автора, может быть полностью доработана для поддержки сторонних управляющих элементов и рендеринга пользовательского XAML.

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

Автор открыт для отзывов и предложений.

Блог автора, Страница для загрузки

Переход от 32 к 64 битным приложениям

2010-04-20T03:43:00.004+04:00

В середине 90x миграция из 16-битных систем на 32-битные шла своим чередом: с одной стороны преимущества явно видны, с другой портирование сводило с ума многих разработчиков, так как требовало изучения новой модели памяти, нового API и измененной арифметики указателей.

В наше время ситуация повторяется, но уже при переходе от 32-битных приложений к 64-битным. К счастью, изменения намного умереннее и для большинства приложений придется сделать совсем немного для успешного запуска 32-битного приложения на 64-битной системе. Благодаря технологиям виртуализации и особенностям CLR, .NET приложение может стать 64-битным автоматически.

Однако, преодоление 2Гб лимита (Ru) (PAE) может стать затруднительным при использовании неуправляемого кода или несовместимых компонентов.

Для неуправляемых приложений все относительно просто, в случае, если они скомпилированы как 32-битное приложение, то они будут работать под управлением Windows-on-Windows (WoW64), предоставляющей совместимую среду для “прозрачного” выполнения 32-битных приложений на всех 64-битных версиях Windows.

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

Для управляемых приложений можно указать как оно должно работать в 64-битной операционной системе: либо как native application(x64), либо под управлением WoW64 (x86).

Существует несколько целевых платформ, на которые разработчик может ориентироваться при разработке: AnyCPU , x86, x64, и Itanium

при компиляции в x86 сборка будет запущена в 32-битной, x86-совместимой CLR;
выбор Itanium приводит к компиляции для работы под управлением 64-битной CLR на компьютерах с процессором Itanium. Планируется прекращение поддержки данной платформы;
компиляция в x64 ограничивает возможность работы 64-битной CLR на компьютерах, с процессорами, поддерживающими набор инструкций AMD64 или EM64T;
AnyCPU задает компиляцию сборки с возможностью работы на любой платформе.

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

В 64-битной ОС:

сборки, скомпилированные как x86 будут выполняться под управлением 32-битной CLR под управлением WoW64;
исполняемые файлы AnyCPU будут выполняться 64-битной CLR;
библиотеки DLL AnyCPU будут выполняться под управлением той же CLR, что и процесс, который их загрузил.

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

32-битная ОС:

	AnyCPU.exe 32-битный процесс	x86.exe 32-битный процесс	x64.exe BadImageFormatException
AnyCPU.dll	успешная загрузка	успешная загрузка	-
x86.dll	успешная загрузка	успешная загрузка	-
x64.dll	BadImageFormatException	BadImageFormatException	-

64-битная ОС:

	AnyCPU.exe 64-битный процесс	x86.exe 32-битный процесс	x64.exe 64-битный процесс
AnyCPU.dll	успешная загрузка	успешная загрузка	успешная загрузка
x86.dll	BadImageFormatException	успешная загрузка	BadImageFormatException
x64.dll	успешная загрузка	BadImageFormatException	успешная загрузка

Чтобы определить на какую платформу рассчитана сборка можно воспользоваться CorFlags Conversion Tool или программно с помощью метода System.Reflection.Module.GetPEKind.

Для неуправляемых приложений информация о платформе сохраняется в PE заголовке, поэтому для просмотра потребуется дампер. Можно воспользоваться стандартными средствами: dumpbin /HEADERS, сейчас этот функционал встроен в link.exe /dump /HEADERS Основное, на что надо обратить внимание в дампе – целевая машина: 8664 machine (x64), 14C machine (x86). В качестве альтернативы, можно попробовать воспользоваться PEDump от Matt Pietrek, но у него несколько проблем: декодировать x64 значение придется вручную (8664), x86 названо как (i386) и он падает при анализе 64-бит DLL на 64-бит Windows 7, впрочем успевая вывести заголовок. При желании можете подкорректировать исходные тексты, чтобы этого избежать, если по каким-либо причинам использование link.exe /dump вас не устраивает.

Стоит ли переходить на 64 бит?

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

Плюсы:

важнейшим преимуществом 64-битных процессов является увеличенное адресное пространство;
оптимизированная 64-битная математика;
64-битной ядро ОС использует больший доступный объем памяти для улучшения многих аспектов работы.

Минусы:

на многое требуется больше памяти (указатели занимают больше, а особенно в управляемом коде, где повсюду ссылки);
эффективная часть процессорного кэша меньше (если сравнивать 32-битный и 64-битный режимы работы) по той же причине;
увеличивается так же и размер кода, за счет дополнительных префиксов и инструкций, содержащих 8-ми байтовые операнды, вместо 4х байтных.

Это ведет к тому, что код, отлично работающий на 32-битах, не содержащий никакой 64-битной арифметики (т.е ни каким другим способом не использующий новые возможности 64-битного процессора), не испытывающий потребности в превышении 2Гб доступной памяти, от работы в 64 битной ОС получит только недостатки: больший потребляемый объем в памяти и некоторое замедление работы.

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

Проблемы использования платформы AnyCPU:

разработка под два различных режима (32-бит и 64-бит) увеличивает сложность продукта и стоимость тестирования. Очень часто неочевидно, что в случае зависимости приложения от неуправляемого кода необходимо удостовериться, что доступны версии этих компонентов в обоих вариантах и самое главное, что нужный из них автоматически выбирается. Большей частью это решается относительно просто за счет функций перенаправления ОС, однако может иногда приводить к проблемам.
некоторые из возможностей недоступны в 64-битном исполнении: отладка x64 кода была добавлена только в CLR v4, до этого отладка была доступна только в смешанном режиме (x86). Функция “Исправить-и-продолжить (edit-and-continue)” до сих пор не поддерживается в x64, та же самая участь постигла возможность исторической отладки (Historical Debugging, IntelliTrace™) в VS 2010. Это следствие различной базы исходных кодов (например, полностью раздельные JIT компиляторы для 32-бит и 64-бит), приводящее к необходимости компромисса и невозможности реализации некоторого функционала из-за огромных временных затрат.

Причины, по которым до сих пор нет Visual Studio 64-бит:

с точки зрения производительности - указатели становятся больше по размеру, соответственно увеличивается размер структур данных, а кэш процессора остается неизменным (уменьшается его эффективная часть) - в основном это приводит к чистой потере производительности. Другими словами, начиная в яме, вы пытаетесь из нее выбраться, используя дополнительную память больше 4Гб как вспомогательное средство для этого. Да, для некоторых огромных проектов это, возможно, и помогло бы, но предпочтительнее прооптимизировать размер используемых структур в первую очередь, что даст возможность обрабатывать больше на том же объеме.
с точки зрения затрат, возможно, самый экономичный способ портировать Visual Studio на 64 бит – это переписать большую его часть на управляемый код, а затем дописать и все остальное. Стоимость такого портирования очень высока, кроме того она приведет к тому, что все известные расширения перестанут работать и придется создавать новую 64-битную экосистему подобно тому, как это делалось для драйверов. Несомненно существуют люди, которые бы могли воспользоваться преимуществами 64-битной версии, но лучше все же эти деньги потратить на уменьшение потребляемой памяти IDE, чем на портирование.

Проблемы при переходе

Как и в случае 32-битной ОС, существует 2Гб ограничение на размер одного объекта, который можно создать при работе 64-битного управляемого приложения на 64-битной ОС.

Во многих случаях сборки работают одинаково на 32-битной и 64-битной версии CLR. Основные причины, по которым исполнение в 64-битной среде CLR может отличаться, следующие:

изменение размеров структур, состоящих из членов, имеющих зависимый от платформы размер, например, указателей;
арифметика с указателями, включающая операции с указанием константных размеров;
некорректное определение P/Invoke или COM-объекта, задающее Int32 для хэндлов вместо IntPtr;
преобразование IntPtr в Int32 при маршалинге.

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

Улучшения в программе установки .NET Framework 4

2010-04-18T03:31:00.001+04:00

Основное на чем сосредоточились разработчики – это Размер, Устойчивость к ошибкам и Производительность.

Размер распространяемого пакета был значительно уменьшен.

Сравнение размеров распространяемого пакета, начиная с 3.5 SP1

	3.5 SP1	4 Beta1	4 Beta2	4 RTM
32bit Client Profile	X	34.5 MB	31.5 MB	28.8 MB
32bit Full	X	77.5 MB	38.5 MB	35.3 MB
32+64bit Client Profile	X	72.5 MB	48.2 MB	41 MB
32+64bit Full	237 MB	162.6 MB	55.9 MB	48.1 MB

Для достижения такого результата были предприняты следующие шаги:

- улучшена используемая технология сжатия, что позволило сократить размер на 15%;
- разделены пакеты для AMD64 и IA64, так как в большинстве случаев они не требуются вместе;
- были идентифицированы сборки функционально идентичные, но включенные ранее в нескольких вариантах под разные архитектуры, несмотря на то, что они были процессорно-нейтральными (без зависимостей от x86 или amd64 архитектуры). Теперь эти сборки включены в одном экземпляре.

Устойчивость к ошибкам значительно повысилась по сравнению с предыдущими релизами. Этого удалось добиться за счет следующего:

- удаление большого числа зависимостей и объединение инсталлятора в единый MSI;

- упрощение MSI за счет удаления и упрощения большого числа скриптов (custom actions);

- было проанализировано огромное число вариантов сбоев при установке, которые поддаются исправлению тем или иным способом, и реализованы шаги, предложенные в соответствующих KB, тем самым добавилась возможность исправить многие известные проблемы при установке, приведя ПК в порядок и, при необходимости, успешно повторить установку;

- после исследования проблем загрузки было решено использовать все три доступных способа для получения файлов: Winhttp, URLMon, и BITS, так как они сбоят в разных ситуациях и в тех случаях, когда один из способов недоступен, второй или третий может исправить ситуацию;

- Client Profile инсталлятор так же упрощен за счет того, что конфигурирование компонентов наподобие ASP.NET и WCF было вынесено в полную версию, так как она зачастую они использовались только при установке на сервер и не использовались клиентскими приложениями.

Производительность. Ключевым показателем производительности является общее время установки. 3.5 SP1 устанавливался в среднем 12-15 минут. В 4й версии среднее время составляет 3-5 минут для клиентского профиля и 5-7 минут для полного. Проведены были следующие работы:

- исправлены ошибки при обработке файлов, устанавливающихся в несколько мест одновременно (Smart Cabbing), ранее их наличие в проекте (WiX) приводило к заметному падению производительности;

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

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

- в CLR была реализована возможность генерации образов в машинном коде на нескольких ядрах параллельно, инсталлятор теперь использует эту возможность, значительно увеличивая скорость работы на многоядерных машинах. Кроме того, на 64битных системах большинство .NET кода по-прежнему использует 32бит, поэтому была убрана синхронная (во время установки) генерация образов в машинных кодах для 64битных сборок;

- можно использовать Web-вариант установки как для клиентского профиля, так и полной версии , при этом для полной версии происходит распараллеливание процессов: пока ставится клиентский профиль .NET Framework, продолжается загрузка остальной части, недостающей до полной версии и если ширина канала достаточна, то вполне может получиться значительная экономия времени, так как к окончанию установки клиентского профиля будет загружено все необходимое для продолжения установки.

Подробнее:

Блог Peter Marcu, пост об улучшениях в инсталляторе

Бесплатная книга: Introducing Microsoft SQL Server 2008 R2

2010-04-15T19:21:00.001+04:00

Доступна для скачивания книга в электронном виде: Introducing Microsoft SQL Server 2008 R2 (Введение в Microsoft SQL Server 2008 R2), написанная Ross Mistry и Stacia Misner: XPS или PDF.

Книга для всех, кому интересен SQL Server 2008 R2 и его возможности.

Книга разбита на 2 части по 5 глав:

PART I DATABASE ADMINISTRATION
CHAPTER 1 SQL Server 2008 R2 Editions and Enhancements
CHAPTER 2 Multi-Server Administration
CHAPTER 3 Data-Tier Applications
CHAPTER 4 High Availability and Virtualization Enhancements
CHAPTER 5 Consolidation and Monitoring

PART II BUSINESS INTELLIGENCE DEVELOPMENT
CHAPTER 6 Scalable Data Warehousing
CHAPTER 7 Master Data Services
CHAPTER 8 Complex Event Processing with StreamInsight
CHAPTER 9 Reporting Services Enhancements
CHAPTER 10 Self-Service Analysis with PowerPivot

Подробная информация

Shock Diamonds and Mach Disks

2010-04-15T17:25:00.000+04:00

Впервые натолкнулся на объяснение интересного эффекта: в выбросе самолетного или ракетного двигателя (особенно на форсаже) часто наблюдается серия дисков или колец. С чем это связано?

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

Руководство Microsoft® по проектированию архитектуры приложений

2010-04-15T17:02:00.002+04:00

Доступно для загрузки второе издание руководства по проектирования архитектуры приложений от команды patterns & practices:

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

Для скачивания книги, придется зарегистрироваться на основном сайте проекта.

AsyncEnumerator Usage Survey for Microsoft's .NET Team

2010-04-15T13:47:00.002+04:00

Jeffrey Richter пытается договориться с Microsoft о добавлении его класса AsyncEnumerator (дополнительно можно почитать тут) или чего-то подобного в одну из будущих версий .NET Framework. Сам класс содержится в его библиотеке Power Threading Library (PowerThreading), упрощающей многопоточное и асинхронное программирование.

Команде Microsoft требуется дополнительная информация, для этого пройдите опрос всего из трех вопросов.

Ниже исходный текст обращения.

I have been working with Microsoft in an attempt to add my AsyncEnumerator (or something like it) into a future version of the .NET Framework.

The good folks at Microsoft would like to gather some more information of how all of you actually use the AsyncEnumerator in your own projects.

To that end, I have created a short, 3 question survey which I would like as many of you to answer as possible.

Please take a few minutes out of your day and go here: http://www.surveymonkey.com/s/FTZPD8Y

Please give as much information as you can and feel comfortable with. The more information we get, the better MS and I can accommodate your asynchronous programming needs in a future version of the .NET Framework.

MS (and I) would also love to see some actual code that leverages the AsyncEnumerator. If you feel comfortable sharing some of your source code, please ZIP it up and e-mail it to me directly at this e-mail address: JeffreyR at Wintellect dot com. Please put “AsyncEnumerator Sample Code” in the subject line and do not expect a reply from me. MS and I will review this code in the next couple of weeks to help make decisions for a future version of the .NET Framework.

Доступна новая версия SOSEX 4

2010-04-14T04:10:00.003+04:00

Steve Johnson выпустил версию SOSEX 4 (великолепное расширение WinDbg для отладки Managed кода), совместимую с .NET 4.0 с существенными улучшениями функциональности.

Для начального знакомства с ним можно почитать несколько довольно старых статей: SOSEX - A New Debugging Extension for Managed Code, Great SOSEX! A Phenomenal .NET Debugging Extension to See the Hard Stuff.

.netTiers Application Framework

2007-04-03T12:28:00.001+04:00

.netTiers - это открытый (open source) бесплатный набор шаблонов для ORM (Object-Relational Mapping), берущий за основу существующую БД SQLServer и автоматически генерирующий персонализированные слои данных приложения (Data Tiers application block) для использования в .NET приложениях. Проект также можно найти на SourceForge.net, на SF его поддерживает один из авторов John Roland.

Для получения приемлемых результатов при применении O/RM технологий критически важно грамотно спроектировать модель БД, .netTiers не исключение из этого правила.

.netTiers генерирует код непосредственно по модели БД без использования вспомогательного XML (или иного) уровня представления. Поэтому использование написанной на "скорую руку" модели, с плохим выбором primary / foreign ключей и т.п. код получится таким же неудачным, так что перед первым использованием .netTiers, даже если это тестовая БД, проверьте еще раз, что она нормализирована и ключи определены верно и, по возможности, добавьте еще несколько не-ключевых полей, которые будут в дальнейшем использованы как фильтры.

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

.netTiers построен на основе платного генератора кода CodeSmith Tools, но выполняется (в январе было заключено соглашение) адаптация под бесплатный Smart Code Generator.

В данный момент для работы потребуется:

Visual Studio 2005
Codesmith 3.x+
Microsoft SQL Server 2000+ (с ограничениями поддерживаются и другие БД)
Microsoft .NET 2.0

Рекомендуются так же:

Microsoft Enterprise Library 2.0
nUnit или Visual Studio Team System

Скачать последнюю версию можно отсюда, там же есть доступ к SVN-репозитарию с текущими исходными кодами.

На RSDN есть тема в средствах разработки, посвященная в том числе и .netTiers.

Интересующиеся технологиями O/R mapping могут посмотреть на подобные бесплатные open source генераторы: EasyObjects.NET (еще один OR/M для Microsoft Enterprise Library) и MyGeneration.

Blogus tags: .NET, nettiers, code generation

Technorati tags: .NET, nettiers, code generation

Все о PInvoke

2007-02-17T20:38:00.001+03:00

Недавно набрел на замечательный FAQ от GotDotNet, посвященный Platform Invoke (PInvoke): возможности вызова unmanaged (native) кода, например, Win32, из приложений .NET. В FAQ много полезной информации.

При использовании PInvoke частенько возникают проблемы, в том числе, не последняя - отсутствие прототипов Win32 API функций в пригодном для вставке в .NET виде. Я использую PInvoke.Net, также можно воспользоваться Interop Declarations for Windows.h Несложно и самому по прототипу составить соответствующее описание, но удобнее и быстрее воспользоваться готовым.

Пригодится так же Microsoft Win32 to Microsoft .NET Framework API Map

Technorati tags: .NET

Blogus tags: .NET

Возможности расширения приложений .NET

2007-02-17T19:05:00.001+03:00

Уже довольно давно не обновлял свой блог: навалилось много работы, домашние дела и вообще много всего. Постараюсь исправиться :)

Microsoft решила более-менее стандартизировать подход к расширению приложений за счет разнообразных плагинов:

Microsoft .NET Framework сильно облегчает встраивание в собственные приложения компонентов, созданных другими разработчиками. Однако это просто, только если известно, к каким компонентам выполняется привязка. Если в момент сборки такие компоненты не известны, что типично для надстроек, то все становится намного сложнее. При расширении своих приложений у разработчиков часто возникают вопросы. Например, надстройки следует хранить в базе данных или на диске? Следует ли в надстройке использовать известный интерфейс или запрашивать тип для активации? Каков наилучший способ использования AppDomain, AppDomainManager и AppDomainSetup?

Эти и другие вопросы решаются в двух выпусках внутреннего бюллетеня CLR за счет введения в библиотеку базовых классов нового пространства имен System.AddIn, которое будет доступно в следующем выпуске Visual Studio^® (с кодовым именем "Orcas").

Подробнее об этом можно узнать на русском языке, прочитав статью из февральского номера CLR Inside Out и ее продолжение Расширяемость приложений .NET, часть 2.

Этому же посвящен блог разработчиков: CLR Add-In Team Blog.

В блоге Jason He's WebLog рассматривается реализация данной модели для Paint.Net. Может быть интересен и блог одного из авторов: Jack Gudenkauf (JackG) WebLog.

Новые библиотеки доступны в январском CTP Visual Studio

Technorati tags: .NET, Visual Studio

Blogus tags: .NET, Visual Studio

Tweak'и для Visual Studio 2005 SP1

2007-01-02T14:45:00.001+03:00

Выпущенный недавно Service Pack (SP) для Visual Studio требует для установки очень много времени и свободного дискового пространства. Однако, эту ситуацию можно улучшить.

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

reg export HKLM\Software\Policies\Microsoft\Windows\Installer installer.reg reg add HKLM\Software\Policies\Microsoft\Windows\Installer /v MaxPatchCacheSize /t REG_DWORD /d 0 /f net stop msiserver start /wait VS80-KBnnnnnn-X86-mmm.exe reg delete HKLM\Software\Policies\Microsoft\Windows\Installer /v MaxPatchCacheSize /f reg import installer.reg net stop msiserver del /q installer.reg 2>nul

Здесь VS80-KBnnnnnn-X86-mmm.exe - имя файла с Service Pack'ом.

Подробнее можно почитать в блоге у автора метода: Save Time and Space for VS 2005 SP1 by Disabling the Patch Cache

Там же доступна информация о встраивании SP в инсталляционный пакет: Slipstreaming Visual Studio 2005 Service Pack 1

Technorati tags: Visual Studio

Blogus tags : Visual Studio

С Новым 2007 годом!

2007-01-01T19:14:00.001+03:00

Поздравляю всех с наступившим 2007 годом!

Дружбы, радости и смеха, Новых знаний, сил, успеха, Жизни в счастье и в ладу, Я Вам искренне желаю В наступающем году!

Всего самого наилучшего!

З.Ы. У меня конец года выдался крайне насыщенным, настолько, что времени на ведение блога не было совсем. Сейчас, наконец, всё пришло в норму, и я смогу продолжить свои заметки.

Professional C#/VB .NET Coding Guidelines

2006-12-19T06:49:00.001+03:00

Компания SubMain выложила в свободный доступ книгу "Professional C#/VB .NET Coding Guidelines", посвященную вопросам соглашения имен, проверенным практикам кодирования и паттернам.

Книга содержит информацию по следующим темам:

Naming Guidelines
Class Member Usage Guidelines
Guidelines for Exposing Functionality to COM
Error Raising & Handling Guidelines
Array Usage Guidelines
Operator Overloading Usage Guidelines
Guidelines for Casting Types
Common Design Patterns
Callback Function Usage
Time-Out Usage
Security in Class Libraries
Threading Design Guidelines
Formatting Standards
Commenting Code
Code Reviews
Additional Notes for VB .NET Developers

Прямая ссылка на книгу. Перед скачиванием необходимо будет указать произвольный e-mail.

Там же на сайте обнаружил удобный бесплатный плагин для Visual Studio: SmartOutline for VS2005, облегчающий работу с регионами.

Easy way to create, edit and remove custom regions - even those that are not possible with the VS built-in tools
Works in any Visual Studio code editor, including custom editors
Works in conjunction with the auto outlining feature of the code editors such as those for VB.NET, C# etc
Persists/saves state (region name, collapsed/expanded) of regions between Visual Studio sessions

Technorati tags: Visual Studio, Книги

Blogus tags : Visual Studio, Книги

Visual Studio Service Pack 1 (SP1)

2006-12-15T18:58:00.001+03:00

Вышел релиз первого сервис пака для Visual Studio.

Подробнее: Visual Studio 2005 Service Pack 1 (SP1)

Through further advancement and feedback, Service Pack 1 also provides over 70 improvements for common development scenarios including:

New processor support (e.g., Core Duo) for code generation and profiling
Performance and scale improvements in Team Foundation Server
Team Foundation Server integration with Excel 2007 and Project 2007
Tool support for occasionally connected devices and SQL Server Compact Edition
Additional support for project file based Web applications
Windows Embedded 6.0 platform and tools support

Technorati tags: Visual Studio

Blogus tags : Visual Studio

База переводов стандартных терминов от Microsoft

2006-12-15T08:32:00.001+03:00

Microsoft предоставила возможность всем желающим бесплатно скачать базу переводов стандартных терминов, содержащую более 9000 определений, переведенных на 45 различных языков. Данные представлены в виде CSV-файла.

via International Project Engineering изнутри

Подборка информации по управлению IT

2006-12-14T06:23:00.001+03:00

На сайте группы компаний Текора опубликована подборка статей и презентаций по следующим темам:

Системы управления проектами в современных организациях
Бизнес кухня и IT кулинария
Менеджер проекта. Взгляд с позиции HR – менеджера
Проектно-ориентированное управление инвестициями и развитием бизнеса и др.

Похожая тематика от Microsoft: How Microsoft Does IT

Рекомендую.

CodeProject: Implementing IDisposable and the Dispose Pattern Properly

2006-12-14T05:59:00.001+03:00

Новая статья на CodeProject: Implementing IDisposable and the Dispose Pattern Properly , содержит подробный обзор проблемы корректного освобождения ресурсов в .NET с примерами реализации.

Ссылки по теме:

Finalization
Garbage Collection: Automatic Memory Management in the Microsoft .NET Framework by Jeffrey Richter
Garbage Collection—Part 2: Automatic Memory Management in the Microsoft .NET Framework by Jeffrey Richter
DG Update: Dispose, Finalization, and Resource Management
Неплохая презентация: Механизм сборки мусора в .NET, жаль практически без комментариев.
GC в .NET
Автоматическое управление памятью в .NET
Для понимания механизма работы сборщика мусора может быть полезна статья: Реализация сборки мусора на С++.

Technorati tags: .NET, статьи

Blogus tags : .NET,статьи

Новые статьи на CodeProject: Neural Networks, конфигурирование .NET 2.0

2006-12-12T01:24:00.001+03:00

На CodeProject появились две интересные (несвязанные между собой) серии статей:

AI : Neural Network for beginners: часть 1, часть 2, часть 3. Статьи посвящены нейронным сетям, теории и практической реализации алгоритмов обучения. Цикл отлично дополняют Neural Networks on C# и статьи по генетическим алгоритмам:

Две очень подробные статьи о конфигурировании приложений в .NET 2.0: Unraveling the Mysteries of .NET 2.0 Configuration и Decoding the Mysteries of .NET 2.0 Configuration

Technorati tags: .NET, Статьи

Blogus tags : .NET,Статьи

Generic Data Structures and Algorithms in .NET2.0

2006-12-11T05:13:00.001+03:00

На CodeProject опубликована статья: Back to basics - Generic Data Structures and Algorithms In .NET 2.0, содержащая подборку различных алгоритмов и структур данных.

Реализовано и готово для повторного использования следующее:

Association - класс, клонирующий функциональность стандартного KeyValuePair<TKey, TValue>, но с возможностью раздельно устанавливать Key и Value.
Bag - структура данных для хранения произвольного количества элементов, подобна множеству, но допускающая одинаковые элементы. Реализована с помощью Dictionary<T, int>.
BinaryTree<T> - реализация двоичного дерева.
Deque - двусвязная очередь.
GeneralTree<T> - деревья.
Vertex<T>, Edge<T>, Graph<T> - классы для построения графов.
Heap - куча.
Matrix - реализация матриц с поддержкой операций.
PascalSet - реализация математического множества с операциями.
PriorityQueue<T> - приоритетная очередь.
SortedList<T> - аналог SortedList<TKey, TValue>, за исключением:

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

VisitableHashtable<Tkey, TValue>, VisitableLinkedList<T>, VisitableList<T>, VisitableQueue<T>, VisitableStack<T> - различные реализации интерфейса IVisitableCollection<T>
Реализованы паттерны: Singleton и Visitor
Методы сортировки: BubbleSorter, GnomeSorter, HeapSorter, InsertionSorter, SelectionSorter, MergeSorter, QuickSorter, ShellSorter, BucketSorter

Автор обещает развивать библиотеку и дальше.

Не пропустите сайт Bruno R. Preiss, на котором представлены реализации фундаментальных структур данных на различных языках программирования: C#, C++, Java, Python, Ruby, Lua, Perl, PHP и текст его книги Data Structures and Algorithms with Object-Oriented Design Patterns

Technorati tags: Алгоритмы, .NET

Blogus tags : Алгоритмы,.NET

Подборка информации по качеству чистых DVD-дисков

2006-12-11T03:55:00.001+03:00

Сайт digitalFAQ опубликовал сводную информацию по качеству DVD-дисков от различных производителей. Там же на сайте доступно расширенное руководство: Blank media quality guide & FAQ.

Technorati tags: Интернет

Blogus tags : Интернет